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ABSTRACT 


Defining  accurate  representations  of  group  behaviors  in  simulations  is  an  expensive,  time- 
consuming  task.  One  reason  for  this  is  that  previously  produced  behaviors  are  often  not 
reusable  within  other  scenarios  or  simulations.  Using  Hierarchical  Task  Networks  (HTNs) 
to  model  military  behaviors  is  a  promising  technique  for  addressing  this  problem.  HTNs 
provide  a  methodology  for  linking  tactical  behaviors,  and  offer  a  potential  system  for  rep¬ 
resenting  the  military  decision-making  process  at  the  tactical  level.  This  thesis  investigates 
the  use  of  HTNs  within  the  COMBATXXI  model.  COMBATXXI  provides  military  plan¬ 
ners  a  detailed  representation  of  combat  operations,  and  supports  analysis  efforts  by  provid¬ 
ing  insights  into  the  effectiveness  of  weapon  systems,  unit  organizations,  and  tactics.  The 
use  of  HTNs  within  COMBATXXI  is  a  relatively  new  concept;  many  aspects  of  HTN  im¬ 
plementation  have  not  been  researched  in  depth.  Work  in  this  thesis  involved  development 
and  testing  of  HTNs  capable  of  executing  a  security  formation  behavior,  and  coordinating 
the  execution  of  other  ground  combat  related  behaviors.  The  HTN-controlled  behaviors 
were  demonstrated  in  a  simulated  version  of  a  United  States  Marine  Corps  live  fire  train¬ 
ing  range.  The  composable  and  dynamic  aspects  of  these  behaviors  eased  the  scenario 
development  process  and  added  tactical  realism  to  the  test  scenario. 
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CHAPTER  1: 

The  Need  for  Dynamic  Behaviors 


The  rapid  advancement  of  technology  has  greatly  increased  the  capabilities  of  modeling 
and  simulation  (M&S)  technologies.  Understanding  the  potential  of  M&S  is  made  diffi¬ 
cult  because  of  the  large  number  and  varying  types  of  models  in  existence.  In  1996,  Dr. 
Joan  Roughgarden  described  a  three-tiered  classification  system  for  models.  The  first  tier 
involved  a  minimal  idea  model  (MIM)  in  which  the  details  of  a  real-world  system  were 
replaced  by  approximations.  The  second  tier  consisted  of  a  minimal  system  model  (MSM) 
that  contained  elements  which  accurately  replicated  some  aspects  of  the  real  world  system. 
The  final  tier  involved  a  synthetic  system  model  (SSM)  which  attempted  to  replicate  nearly 
all  physical  aspects  of  a  real  world  system  [1,  pp.  35-36]. 

Numerous  MIMs  and  MSMs  have  proven  useful  for  providing  important  knowledge  of 
real-world  systems.  A  major  advantage  of  these  models  is  that  they  are  relatively  simple  to 
develop  in  comparison  to  SSMs.  If  constructed  properly,  MIMs  and  MSMs  can  provide  in¬ 
sights  about  the  system  being  modeled.  However,  abstracting  too  many  real  life  details  can 
result  in  limitations  on  the  amount  of  useful  information  a  model  can  provide.  Additionally, 
this  can  prevent  a  model  from  being  reusable  in  other  scenarios  and  contexts. 

For  one  to  properly  implement  actual  military  behaviors  into  simulations,  it  is  necessary 
to  consider  the  type  of  operations  being  conducted,  and  the  level  of  detail  provided  by  the 
simulation.  Only  then  is  it  possible  to  decide  which  military  behaviors  must  be  modeled  ex¬ 
plicitly  (in  a  detailed  manner)  and  which  behaviors  can  be  modeled  implicitly  (abstracted 
out  of  the  model).  As  technology  has  progressed,  simulations  have  gained  the  ability  to 
represent  increasingly  accurate  versions  of  reality.  To  avoid  problems  caused  by  the  ex¬ 
cessive  use  of  implicit  modeling,  organizations  have  sought  to  employ  simulations  that 
model  the  real  world  at  a  detailed  level.  Combined  Arms  Analysis  Tool  for  the  21st  Cen¬ 
tury  (COMBATXXI)  is  one  model  that  the  military  has  built  for  such  use. 

COMBATXXI  is  a  “joint,  high-resolution,  closed-form,  stochastic,  discrete  event,  en¬ 
tity  level  structure  analytical  simulation”  [2].  It  is  currently  used  by  the  United  States 
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Army  (USA)  and  United  States  Marine  Corps  (USMC)  in  the  “research,  development,  and 
acquisition  (RDA)  and  advanced  concepts  and  requirements  (ACR)  M&S  domains”  [2], 
COMBATXXI  has  the  ability  to  model  numerous  aspects  of  combat  operations,  including 
ground  forces,  fixed-wing  and  rotary-wing  aircraft,  combat  service  support  units,  and  fu¬ 
ture  forces.  Detailed  terrain  maps  provide  data  for  simulated  military  operations  in  all  types 
of  theaters,  including  amphibious  environments  for  USMC  forces.  COMBATXXI  provides 
military  planners  a  detailed  representation  of  combat  operations.  This  information  supports 
the  analysis  of  combat  operations  by  providing  insights  into  the  effectiveness  of  weapon 
systems,  unit  organizations,  and  tactics. 

Unfortunately,  this  knowledge  does  not  come  without  a  cost.  Developing  the  inputs  for 
running  a  simulation  in  COMBATXXI  requires  a  significant  investment  in  time  and  money. 
Building  the  input  scenario  for  a  recent  Army  study  of  a  new  ground  combat  vehicle  (GCV) 
took  nine  trained  analysts  approximately  seven  months  to  complete  [3],  Even  an  entry  level 
tutorial  focused  on  a  mechanized  infantry  platoon  requires  an  estimated  twelve  hours  to 
program. 

One  of  the  reasons  for  such  a  long  development  time  is  that  high-resolution  simulations 
require  entity  behaviors  to  be  programmed  in  a  highly  detailed  manner.  Additionally,  these 
behaviors  are  often  not  reusable  in  other  scenarios,  or  even  by  other  entities  in  the  same  sim¬ 
ulation.  There  is  no  simple  solution  to  such  problems;  obtaining  high-resolution  insights 
from  a  computer  simulation  will  always  require  a  great  deal  of  work.  Creating  mechanisms 
to  ease  this  process  first  requires  a  basic  understanding  of  military  operations. 

1.1  Military  Doctrine 

The  United  States  Armed  Forces  differ  from  civilian  businesses  due  to  their  manner  of 
their  funding,  their  large  number  of  personnel,  and  the  chaotic  nature  of  their  intended 
operating  environment  -  warfare.  Training  a  workforce  in  a  consistent  and  effective  manner 
is  a  serious  issue  for  organizations  that  have  a  large  numbers  of  employees  with  a  high 
personnel  turnover  rate.  To  accomplish  this  task  in  an  efficient  manner,  the  Army  and  the 
Marine  Corps  adopted  a  set  of  procedures  from  the  systems  engineering  (SE)  field  that  are 
known  as  the  systems  approach  to  training  (SAT)  [4]. 

According  to  the  SAT  manual,  “the  SAT  was  created  to  manage  the  instructional  process 
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for  analyzing,  designing,  developing,  implementing,  and  evaluating  instruction.  ...  It  is  a 
dynamic,  flexible  system  for  developing  and  implementing  effective  and  efficient  instruc¬ 
tion  to  meet  current  and  projected  needs”  [4,  p.  iii].  Originally  intended  as  a  method 
of  instruction  for  formal  schools,  the  SAT  process  was  applied  to  training  and  operations 
throughout  the  Marine  Corps. 

A  Marine  Air  Ground  Task  Force  (MAGTF)  is  divided  into  four  main  categories:  the 
ground  combat  element  (GCE),  the  air  combat  element  (ACE),  the  logistics  combat  ele¬ 
ment  (LCE),  and  the  command  element  (CE).  Each  MAGTF  branch  has  a  series  of  SAT 
documents  called  Training  and  Readiness  (T&R)  manuals.  These  documents  provide  a 
detailed  explanation  of  operational  tasks  in  which  Marines  are  required  to  maintain  profi¬ 
ciency.  Additionally,  T&R  manuals  specify  tasks  for  individuals  and  units  at  all  levels,  and 
arrange  these  tasks  in  a  hierarchical  manner.  Whether  one  is  a  regimental  commander,  or  a 
machine  gun  team  leader,  the  T&R  manuals  contain  detailed  descriptions,  instructions,  and 
performance  standards  for  the  tasks  that  one’s  unit  must  be  able  to  accomplish. 

Literature  concerning  military  actions  is  not  limited  to  the  USMC  T&R  manuals.  There 
exists  a  great  number  of  military  publications  that  specify  how  units  should  execute  tactical 
actions  in  scenarios  ranging  from  counterinsurgency  operations,  to  full  scale  high  inten¬ 
sity  conflict  in  urban  or  amphibious  settings.  Examples  of  doctrinal  military  publications 
pertinent  to  this  thesis  are  listed  below:1 

1.  Marine  Corps  Doctrinal  Publication  (MCDP)  1  “Warfighting” 

2.  MCDP  1-0  “Operations” 

3.  Marine  Corps  Warfighting  Publication  (MCWP)  3-1 1.2  “Marine  Rifle  Squad” 

4.  MCWP  5-1  “Marine  Corps  Planning  Process” 

While  no  written  document  can  perfectly  illustrate  the  dynamics  of  actual  combat,  the 
above  listed  publications  provide  detailed  descriptions  of  the  basic  behaviors  that  military 
units  are  expected  to  perform.  Potentially  of  even  more  importance,  the  listed  publications 
provide  insights  into  how  military  members  are  trained  to  think.  Understanding  the  prin¬ 
ciples  and  the  actions  in  these  publications,  as  well  as  in  the  USMC  T&R  manuals,  can 

1  Similar  information  can  be  found  in  United  States  (U.S.)  Army  Field  Manual  (FM)  3-0  “Operations”  and 
FM  3-21.8  “The  Infantry  Rifle  Platoon  and  Squad.” 
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play  a  vital  role  in  programming  agent  behaviors  that  are  representative  of  actual  military 
maneuvers. 

1.2  Composable  Behaviors 

Defining  accurate  representations  of  group  behaviors  in  simulations  is  an  expensive,  time- 
consuming  task.  One  of  the  main  reasons  for  this  is  that  previously  produced  behaviors  are 
often  not  reusable  within  other  scenarios  or  other  simulations.  The  concept  of  composable 
behaviors  has  the  potential  to  create  “an  easy  to  use,  adaptive  and  flexible  framework  for 
simulating  group  behaviors”  [5]. 

Reusable  components  help  systems  users  by  enabling  them  to  leverage  previous  work  for 
the  purpose  of  easing  future  work.  There  are  many  ways  to  define  reusability;  the  two 
meanings  most  relevant  to  this  thesis  involve  template  based  reuse  and  direct  reuse.  Tem¬ 
plate  based  reuse  is  where  previously  developed  components  are  used  as  guides  to  build 
new  components.  The  use  of  templates  can  substantially  reduce  the  effort  required  to  build 
a  new  component;  however,  a  new  component  still  needs  to  be  created.  Direct  reuse  is  when 
a  component  can  be  directly  utilized  in  a  scenario  without  the  need  to  create  a  new  version. 
To  support  a  range  of  contexts,  this  approach  uses  parameters  that  allow  the  component  to 
adjust  to  different  contexts.  The  goal  of  this  work  is  to  support  direct  reuse. 

Different  meanings  are  also  attributed  to  the  term  composability.  Addressing  the  general 
notion  of  composability  is  a  complex  problem  and  well  beyond  the  scope  of  this  thesis; 
therefore,  this  research  will  refer  to  composability  as  the  “capability  to  select  and  assem¬ 
ble  simulation  components  in  various  combinations  into  valid  simulation  systems  to  satisfy 
specific  user  requirements”  [6,  p.  1].  Applied  to  the  field  of  automated  behaviors,  compos¬ 
ability  refers  to  the  process  by  which  primitive  behaviors  are  combined  to  form  high-level 
composite  behaviors.  These  composite  behaviors  are  then  executed  by  simulation  enti¬ 
ties.  Within  military  simulations,  the  creation  of  such  a  capability  promises  to  increase  the 
realism  of  automated  behaviors  and  to  ease  the  scenario  development  process. 

According  to  Mikel  Petty,  “the  defining  characteristic  of  composability  is  the  ability  to 
combine  and  recombine  components  into  different  simulation  systems  for  different  pur¬ 
poses”  [6,  p.  1].  The  application  of  a  composable  behavior  system  with  this  degree  of 
flexibility  has  numerous  benefits  to  military  simulations.  However,  achieving  this  goal  first 
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requires  a  solid  foundation,  particularly  in  the  creation  of  low-level  supporting  behaviors. 
As  stated  by  Joshua  Summers,  “a  primitive  behavior  is  an  action  that  is  not  decomposable 
into  sub-actions  and  that  is  used,  combined  with  other  primitive  behaviors,  to  develop  com¬ 
posite  behaviors”  [7,  p.  2],  The  creation  of  a  composable  behavior  system  requires  such 
primitive  behaviors  to  be  identified  early  in  development  processes,  and  coded  in  a  manner 
that  ensures  maximum  reusability. 

An  important  goal  of  this  thesis  is  to  apply  the  concept  of  composable  behaviors  to  mili¬ 
tary  operations.  It  is  important  to  recognize  that  military  tasks  are  hierarchical  in  nature. 
Simple  military  behaviors,  such  as  fire  and  movement,  play  vital  roles  in  complex  military 
behaviors  such  as  flanking  attacks  and  movements  to  contact.  Additionally,  many  of  the 
fundamental  actions  and  mindsets  of  small  military  forces  in  one  environment  remain  ap¬ 
plicable  to  the  operations  of  a  larger  force  in  a  different  environment.  These  factors  create 
a  direct  tie  to  the  concept  of  composable  behaviors,  which  can  be  described  informally,  as 
building  complex  behaviors  from  simple  ones  in  a  systematic  manner. 

1.3  Hierarchical  Task  Networks 

To  be  able  to  represent  complex  operations  such  as  mechanized  warfare  or  military  oper¬ 
ations  in  urban  terrain  (MOUT),  it  is  first  necessary  to  model  simple  behaviors  that  form 
the  foundation  for  such  complex  maneuvers.  One  method  to  accomplish  this  is  through 
the  use  of  automated  planning  techniques  known  as  hierarchical  task  networks  (HTNs). 
In  general,  HTNs  can  be  described  as  “a  formalism  for  representing  hierarchical  plans”  in 
which  high-level  tasks  are  decomposed  into  simpler  tasks  [8,  p.  2],  This  method  can  enable 
the  accomplishment  of  high-level  strategies  through  the  coordinated  actions  of  individual 
entities  [8,  p.  2].  Using  the  HTN  methodology  to  model  fundamental  military  behaviors  is 
a  promising  technique  for  applying  the  concept  of  composable  behaviors  to  military  sim¬ 
ulations.  HTNs  not  only  provide  a  method  for  linking  tactical  behaviors,  they  also  offer 
a  potential  technique  for  representing  the  military  decision-making  process  at  the  tactical 
level.2 

Military  leaders  devise  solutions  to  problems  in  one  of  three  ways:  they  select  a  previously 

2  HTNs  are  appropriate  for  representing  the  human  decision  making  process  in  models  like  COMBATXXI 
because  this  model  represents  the  net  effect  of  human  decision  making  and  not  the  actual  process. 
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learned  technique,  they  modify  a  previously  learned  technique,  or  they  devise  a  unique 
solution.  Simulating  the  decision-making  process  of  military  leaders  is  a  complex  task  but, 
if  feasible,  would  be  of  great  value  to  simulations.  Modeling  military  behaviors  with  HTNs 
provides  a  potential  way  to  represent  many  aspects  of  this  process  at  the  tactical  level.  Their 
ability  to  do  so  lies  in  the  fact  that  HTNs  contain  numerous  paths  for  reaching  a  single  goal 
state.  The  selection  of  which  path  to  utilize  depends  upon  an  agent’s  current  situation  and 
the  HTN  parameters.  This  methodology,  in  combination  with  the  concept  of  composable 
behaviors,  holds  the  potential  to  simulate  military  actions  in  a  more  realistic  manner. 

Applied  properly,  agents  executing  HTNs  of  simple  behaviors  would  choose  the  course 
of  action  best  suited  to  their  current  situation.  Because  composable  behaviors  are  being 
utilized,  the  actions  caused  by  HTNs  of  simple  behaviors  would  directly  impact  the  auto¬ 
mated  decision-making  conducted  for  complex  tasks  (also  controlled  by  HTNs).  The  result 
of  this  would  be  the  creation  of  a  non-scripted  action  that  is  uniquely  tailored  to  the  given 
situation. 

This  concept  can  be  illustrated  by  an  example  of  a  military  unit  conducting  a  standard 
attack  on  an  enemy  position.  When  conducting  an  attack,  military  members  will  often  con¬ 
duct  fire  and  movement  in  order  to  close  the  distance  between  themselves  and  their  enemy. 
If  one  element  of  the  unit  were  to  begin  receiving  heavy  volumes  of  enemy  fire,  that  spe¬ 
cific  element  could  automatically  change  its  behavior  from  fire  and  movement,  to  attack  by 
fire.  This  action  would  place  additional  amounts  of  suppression  on  the  enemy  force,  thus 
allowing  adjacent  friendly  elements  to  successfully  close  to  within  hand  grenade  range  of 
the  enemy  force.  This  is  an  example  of  how  the  correct  application  of  simple  behaviors 
(fire  and  movement,  attack  by  fire)  could  result  in  the  emergence  of  more  complex  military 
behaviors  (fix  and  flank).  This  concept  could  be  achieved  by  modeling  basic  military  be¬ 
haviors  with  HTNs,  and  by  linking  them  together  in  a  composable  manner.  Should  work 
in  this  thesis  prove  successful,  it  could  lead  to  more  realistic  modeling  of  complex  military 
behaviors. 


1.4  Focus  of  Research 

Research  in  this  thesis  is  divided  into  three  main  phases.  The  first  phase  involves  the 
research  of  techniques  utilized  to  created  automated  behavior  in  simulations  and  games. 
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This  section  investigates  the  evolution  of  techniques  for  creating  automated  behavior  that 
have  been  used  in  the  military,  in  the  gaming  industry,  and  in  academia.  It  also  highlights 
notable  applications  of  these  techniques  which  should  be  of  interest  to  the  Department  of 
Defense  (DOD). 

Additionally,  this  phase  discusses  the  topic  of  behavior  validation.  As  M&S  techniques 
have  progressed,  a  heavy  emphasis  has  been  placed  on  formalizing  the  approaches  utilized 
to  certify  systems.  The  validation  of  automated  human  behavior  is  a  vital,  yet  underde¬ 
veloped  field.  This  section  discusses  the  history  of  human  behavior  representation  (HBR) 
validation,  deficiencies  of  current  procedures,  and  newly  proposed  methods  of  validation. 
If  successfully  implemented,  these  techniques  promise  to  revolutionize  M&S  usage  across 
numerous  communities. 

The  second  phase  of  this  research  involves  the  study  of  military  doctrine  and  tactics.  The 
creation  of  artificial  intelligence  (AI)  that  is  able  to  adequately  represent  human  behavior 
first  requires  an  understanding  of  the  principles  and  thought  processes  upon  which  actual 
military  behaviors  are  based.  Human  behaviors  in  simulations  are  not  adequately  repre¬ 
sented  when  entities  are  scripted  to  mimic  the  actions  of  a  military  force.  Therefore,  this 
phase  discusses  several  important  principles  of  military  operations,  and  illustrates  their  use 
in  a  variety  of  scenarios.  An  additional  purpose  of  this  phase  is  to  scope  the  implementa¬ 
tion  portion  of  this  thesis.  While  the  concept  of  a  basic  infantry  attack  may  initially  appear 
to  be  simple,  this  fundamental  military  action  includes  numerous  sub-tasks  and  decision 
points.  By  identifying  and  analyzing  these  complexities,  this  section  provides  guidance  for 
the  creation  of  an  AI  system  that  can  execute  a  basic  infantry  attack. 

The  final  phase  of  this  thesis  documents  efforts  to  create  dynamic  tactical  behaviors  in 
COMBATXXI.  The  majority  of  these  efforts  involve  the  use  of  a  specialized  type  of 
HTN.  While  differences  exist  between  this  HTN  implementation  and  other  more  tradi¬ 
tional  HTNs,  both  forms  retain  many  of  the  same  basic  properties.  For  the  purpose  of  this 
thesis,  COMBATXXI  HTNs  will  simply  be  referred  to  as  HTNs. 

1.5  Research  Questions 

The  use  of  HTNs  within  COMBATXXI  is  a  relatively  new  concept;  many  aspects  of  HTN 
implementation,  including  reusability  and  scalability,  have  not  been  formally  researched. 
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Work  in  this  thesis  will  involve  construction  of  HTNs  for  infantry  behaviors,  validation  of 
these  HTNs  in  standard  scenarios,  and  reusability  and  scalability  testing  of  these  HTNs. 
With  respect  to  the  modeled  behaviors,  this  section  will  seek  to  answer  the  following  ques¬ 
tions: 

Representation:  Do  HTNs  increase  a  simulation’s  ability  to  represent  combat  scenarios? 
Efficiency:  Does  the  use  of  HTNs  create  efficiencies  in  scenario  construction? 
Composability:  Can  HTNs  of  tactical  behaviors  operate  in  conjunction  with  other  HTNs? 
Reusability:  Can  HTNs  be  successfully  utilized  in  different  scenarios  and  contexts? 
Scalability:  Are  HTNs  able  to  control  the  actions  of  various  sized  units? 

Parameters:  What  parameters  are  appropriate  for  HTNs  of  military  behaviors? 

Creation:  Can  doctrinal  military  publications  serve  as  useful  guides  for  creating  HTNs  of 
tactical  behaviors? 


1.6  Benefits  of  Study 

Military  history  is  rich  with  examples  of  armies  that  did  not  adapt  to  changing  circum¬ 
stances,  and  were  defeated  because  they  attempted  to  fight  conflicts  in  the  same  manner  as 
they  had  fought  in  previous  wars.  Differences  in  environments,  in  unit  organizations,  and 
in  weapon  systems,  can  all  have  a  significant  effect  on  how  wars  are  conducted.  To  remain 
relevant,  simulations  that  are  utilized  to  prepare  military  forces  must  be  mindful  of  these 
changes.  One  of  the  ways  to  do  this  is  to  identify,  understand,  and  accurately  represent  the 
fundamental  behaviors  that  are  seen  on  the  field  of  battle. 

The  products  of  this  thesis  will  satisfy  requests  for  HTNs  of  infantry  behaviors  that  can  be 
utilized  in  COMBATXXI  scenarios  conducted  by  the  Operations  Analysis  Division  (OAD), 
Marine  Corps  Combat  Development  Command  (MCCDC).  Because  the  HTNs  will  model 
fundamental  infantry  behaviors  and  will  be  based  upon  doctrinal  military  publications, 
these  HTNs  will  provide  additional  realism  in  a  wide  range  of  scenarios. 

Motivating  factors  for  this  thesis  also  include  several  long  term  goals.  This  thesis  is  in¬ 
tended  to  be  part  of  the  foundational  research  for  a  new  method  of  behavior  representation 
that  could  revolutionize  the  manner  in  which  COMBATXXI  scenarios  are  created.  Addi¬ 
tional  benefits  of  this  thesis  include  the  following: 
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•  Examine  the  feasibility  of  using  dynamic  HTN-controlled  behaviors  to  model  mili¬ 
tary  operations. 

•  Add  relevant  and  realistic  tactical  actions  to  the  growing  libraries  of  HTN-based 
behaviors. 

•  Demonstrate  HTN  reusability  and  scalability. 

•  Identify  parameters  that  are  needed  to  model  tactical  behaviors  with  HTNs. 

•  Establish  a  link  between  doctrinal  military  behaviors  and  COMBATXXI  behaviors. 

This  thesis  has  direct  ties  to  several  science  and  technology  objectives  (STOs)  described 
in  the  “2012  U.S.  Marine  Corps  Science  &  Technology  (S&T)  Strategic  Plan.”  The  first 
area  in  which  this  thesis  would  benefit  the  Marine  Corps  is  in  the  acquisition  of  combat 
systems.  Numerous  STOs  in  the  maneuver  and  fires  categories  describe  the  need  to  develop 
new  technologies.  These  include  but  are  not  limited  to  MVR  STO-3:  Advanced  robotic 
systems  in  support  of  ground  maneuver;  MVR  STO-5:  Vehicle  and  surface  craft  design 
for  Marine  usability,  habitability,  and  survivability;  and  finally  Fires  STO-4:  Increased 
capabilities  and  reduced  weight  of  all  ground  combat  weapons  systems.  Progress  in  each 
of  these  STOs  will  require  simulations  similar  to  the  GCV  study  previously  mentioned  in 
this  thesis.  The  creation  of  more  realistic  behaviors  in  COMBATXXI  could  benefit  such 
studies  by  reducing  wasteful  spending  and  by  helping  to  ensure  the  selection  of  the  best 
combat  system. 
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CHAPTER  2: 

Automated  Behavior  History  and  Evolution 


Constructing  a  scenario  within  simulations  such  as  COMBATXXI  requires  the  scenario 
developer  to  specify  detailed  behaviors  for  every  entity  within  the  simulation.  Such  sim¬ 
ulations  present  several  advantages  and  disadvantages.  The  detail-oriented  nature  of  the 
simulation  allows  programmers  to  specify  the  exact  behaviors  of  their  agents.  This  at¬ 
tribute  gives  simulations  the  potential  to  accurately  represent  military  operations.  How¬ 
ever,  achieving  representative  behavior  is  not  necessarily  an  easy  task.  First,  the  scenario 
developer  is  responsible  for  constructing  every  part  of  a  military  operation;  this  information 
includes,  but  is  not  limited  to,  force  structures,  equipment,  actions,  and  event  coordination. 
This  is  a  process  that  not  only  takes  a  great  deal  of  time,  but  also  one  that  requires  the  pro¬ 
grammer  to  have  an  intimate  knowledge  of  the  military  operation  to  be  modeled.  If  models 
are  produced  without  an  adequate  amount  of  development  time,  or  by  scenario  designers 
who  lack  knowledge  of  military  operations,  then  the  produced  scenario  is  at  risk  of  not 
being  able  to  represent  the  operation  to  a  sufficient  degree  of  accuracy. 

An  important  goal  for  this  thesis  is  to  ease  the  development  of  simulation  scenarios  by 
automating  the  creation  of  certain  behaviors.  Several  techniques  offer  potential  solutions 
to  this  problem.  The  following  section  provides  a  summary  of  AI  techniques  that  have 
been  utilized  to  create  tactical  behaviors  in  the  military  and  gaming  domains.  While  the 
purposes  of  military  simulations  and  video  games  are  different,  the  tactical  behaviors  they 
contain  have  many  characteristics  in  common.  The  development  environment  within  both 
domains  also  have  similar  time  constraints;  being  able  to  develop  good  behaviors  quickly 
is  an  important  factor  for  success. 

2.1  Reactive  Planning  Techniques 

Reactive  planning  methods  include  finite  state  machines  (FSMs)  and  behavior  trees  (BTs). 
Within  these  systems,  non-player  characters  (NPCs)  follow  a  “pre-programmed  strategy 
that  specifies  how  the  NPC  should  react  in  the  game  depending  on  the  current  state/node 
and  conditions  that  currently  hold  in  the  game-world”  [9,  p.  30].  The  relative  simplicity  of 
these  techniques  has  resulted  in  their  widespread  use  in  the  gaming  industry. 
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Figure  2.1:  Basic  Finite  State  Machine  for  a  Non-Player  Character,  from  [10] 


2.1.1  Finite  State  Machines 

One  of  the  traditional  ways  for  encoding  agent  artificial  intelligence  is  through  the  use  of 
FSMs.  This  structure  is  mainly  comprised  of  a  collection  of  states  and  a  series  of  transi¬ 
tions  between  those  states.  FSMs  have  been  successfully  employed  in  many  video  games 
and  simulations  that  called  for  agents  to  carry  out  a  simple  set  of  behaviors.  Video  game 
programmer  Jeff  Orkin  describes  FSMs  as  structures  which  tell  “AI  exactly  how  to  behave 
in  every  situation”  [11,  p.  3]. 

This  attribute  presents  both  advantages  and  disadvantages.  For  software  developers,  FSMs 
are  relatively  easy  to  understand  and  implement.  They  can  often  be  implemented  by  uti¬ 
lizing  basic  if-then-else  statements  [10,  p.  9].  As  the  demand  for  more  realistic  behaviors 
increased,  the  limitations  of  FSMs  became  apparent.  If  used  to  represent  anything  but  the 
simplest  of  behaviors,  FSMs  become  extremely  complex.  This  complexity  makes  modi¬ 
fying  FSMs  a  tedious  task.  Figure  2.1  and  Figure  2.2  depict  how  quickly  an  FSM  based 
system  can  become  unmanageable. 

2.1.2  Embedded  Behaviors  and  Affordances 

The  affordance  concept  is  used  to  tie  physical  characteristics  of  some  object  or  situation 
to  a  set  of  actions  made  possible  by  the  presence  of  the  object  or  situation.  This  idea  was 
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Figure  2.2:  Finite  State  Machine  Complexity,  from  [11] 

introduced  by  James  Gibson  as  part  of  his  work  in  psychology  [12].  Additional  information 
on  affordances  can  be  found  in  the  following  sources: 

•  An  Activity  Theory  Approach  to  Ajfordance  by  Baerentsen  and  Trettvik  [13] 

•  Gibsonian  Affordances  for  Roboticists  by  Chemero  and  Turvey  [14] 

•  An  Affordance-Based  Perspective  on  Human-Machine  Interface  Design  by  Lintern 

[15] 

•  The  MACS  Project:  An  Approach  to  Affordance-Inspired  Robot  Control  by  Rome  et 
al.  [16] 

The  affordance  concept  has  been  refined  and  used  in  a  wide  range  of  disciplines  from  indus¬ 
trial  design  to  AI.  In  the  gaming  industry,  this  approach  has  been  used  to  help  agents  make 
better  context  dependent  choices.  AI  programmer  Sergio  Garces  describes  how  embedding 
relevant  information  into  terrain  is  a  viable  technique  for  enabling  agents  to  identify  context 
that  triggers  an  appropriate  set  of  possible  behaviors: 


Try  to  get  someone  to  explain  to  you  how  to  pick  a  good  cover  point  or  to  find 
an  advantageous  defensive  position,  and  they’ll  have  a  hard  time,  but  they’ll 
quickly  give  several  examples  when  they  see  a  map.  It’s  so  effective  that  fre¬ 
quently  the  easiest  way  to  get  AI  to  ‘understand’  a  map  is  to  spell  everything 
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out  manually.3  With  proper  tools,  it  shouldn’t  be  a  problem  for  the  designers  to 
annotate  [their]  maps  with  the  information  that  the  AI  needs  to  do  its  reason¬ 
ing:  cover  points,  camping  spots,  possible  attack  avenues  towards  a  coveted 
resource,  areas  that  are  interesting  to  defend,  etc...  Sometimes,  instead  of  plac¬ 
ing  this  information  in  the  map  directly,  [it  can  be  encoded]  in  the  objects  that 
will  go  in  the  map.  [17,  p.  3] 


According  to  Lars  Liden,  “waypoints  can  be  exploited  to  efficiently  calculate  information 
about  the  strategic  value  of  particular  world  locations”  [18,  p.  211].  Within  this  thesis, 
embedded  behaviors  will  be  referred  to  as  affordances.  For  many  years,  the  gaming  realm 
has  utilized  this  approach  to  control  NPCs  through  the  use  of  scripts  and  hints.  As  stated  by 
Straatman  and  Beij,  “the  scripts  define  how  the  AI  responds  to  specific  situations,  whereas 
the  hints  indicate  where  the  AI  could  perform  specific  actions”  [19,  p.  2].  Figure  2.3 
provides  an  example  of  how  embedded  scripts  can  be  used  to  trigger  specific  NPC  actions, 
and  Figure  2.4  illustrates  how  hints  embedded  into  nodes  can  be  used  to  refine  NPC  ambush 
behaviors. 

While  useful  for  many  applications,  affordances  run  into  limitations  as  NPCs  are  expected 
to  respond  to  more  dynamic  situations.  According  to  Straatman  and  Beij,  “the  need  to 
fight  anywhere,  against  threats  from  any  direction  cannot  be  supported  using  this  approach 
without  placing  loads  of  hints.  Statically  placed  hints  are  less  effective  when  positions  of 

3In  this  context,  the  term  AI  refers  to  an  agent  executing  a  behavior.  The  academic  and  gaming  realms 
sometimes  use  the  term  in  this  manner. 


Figure  2.3:  Common  Embedded  Behavior  Approach,  from  [20] 
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Figure  2.4:  Using  Embedded  Information  to  Find  Ambush  Locations,  from  [18] 

the  opposing  forces  are  hard  to  predict,  or  when  the  environment  is  likely  to  change”  [19,  p. 
2].  Despite  such  issues,  affordances  remain  relevant  tools  for  behavior  control.  Embedded 
hints  and  scripted  tactics  can  still  be  useful  in  “exceptional  situations  where  the  default 
tactics  won’t  work  or  the  default  behavior  does  not  provide  the  intended  behavior”  [19,  p. 
2]. 

It  should  be  noted  that  the  previously  described  affordances  contain  relatively  low  level 
information.  This  aspect  generally  increases  the  number  of  affordances  required  to  achieve 
desired  behaviors.  An  alternate  technique  would  be  to  program  affordances  with  higher 
level  information  that  is  relevant  in  a  broader  context.  This  approach  would  mitigate  the 
need  to  create  large  numbers  of  affordances. 


2.1.3  Behavior  Trees 

Behavior  trees  are  a  more  recently  developed  technique  for  producing  realistic  actions 
within  simulations.  If  created  in  coordination  with  a  domain  expert,  behavior  trees  have 
the  potential  to  accurately  represent  many  aspects  of  the  human  decision  making  process. 
One  of  the  first  major  games  to  successfully  implement  behavior  trees  was  Halo  2  in  2004. 
Since  then,  they  have  been  implemented  in  numerous  additional  games. 
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Behavior  trees  are  largely  composed  of  two  different  task  types:  leaf  tasks  and  composite 
tasks.  Leaf  tasks  “check  a  condition  or  execute  some  code”  [10,  p.  14].  The  actions  that 
leaf  tasks  perform  are  normally  some  type  of  script.  Composite  tasks  are  composed  of  leaf 
tasks  or  subordinate  composite  tasks;  their  return  value  depends  upon  the  execution  of  their 
child  tasks  [10,  p.  14].  Though  rare,  it  is  possible  for  composite  tasks  to  execute  actions  of 
their  own  [9,  p.  10]. 

Several  options  exist  for  creating  behavior  trees  capable  of  accomplishing  interesting  be¬ 
haviors.  Figure  2.5  illustrates  one  such  behavior  tree  which  varies  the  success  requirement 
for  composite  tasks.  Composite  tasks  denoted  by  an  arrow  require  all  child  tasks  to  be 
successful;  composite  tasks  denoted  by  a  question  mark  only  require  one  child  task  to  be 
successful.  As  depicted  in  Figure  2.6,  the  order  that  child  tasks  are  attempted  is  normally 
from  left  to  right.  However  the  behavior  can  be  made  non-deterministic  by  using  a  random 
process  to  select  which  child  task  is  executed  first.  Composite  tasks  can  also  be  written  so 
that  they  attempt  to  perform  multiple  child  tasks  at  once. 

Behavior  trees  provide  the  advantage  of  being  simple  to  understand  and  to  implement. 
This  is  part  of  the  reason  they  are  extremely  popular  within  the  gaming  industry.  Professor 
Stavros  Vassos  states  that  behavior  trees  provide  “separation  between  the  work  of  the  pro¬ 
grammer  and  the  game  designers,”  and  that  new  methods  are  constantly  being  developed 
to  give  them  more  capability  [10,  p.  29]. 

Unfortunately,  this  technique  has  some  inherent  disadvantages.  First,  behavior  trees  be¬ 
come  very  large  if  they  represent  anything  but  the  simplest  human  decision  making  pro¬ 
cess.  Second,  the  complexity  of  large  behavior  trees  makes  modifying  their  structure  late 
in  the  development  process  a  tedious  process.  These  limitations  in  behavior  trees  have  led 
some  researchers  to  seek  alternate  solutions  for  producing  automated  behavior. 


2.1.4  Emergence  of  an  Alternate  Automated  Behavior  Technique 

The  2002  video  game  No  One  Lives  Forever  2  (NOLF2)  was  an  example  of  a  game  in  which 
the  designers  sought  to  implement  a  different  method  of  behavior  control.  To  achieve  more 
realistic  behaviors  with  its  agents,  NOLF2  would  assign  goals  to  characters;  the  goals  were 
assigned  in  such  a  manner  as  to  be  applicable  to  the  agent’s  current  situation. 
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Figure  2.5:  BT  Composite  Tasks,  from  [10]  Figure  2.6:  BT  Execution  Or¬ 

der,  from  [9] 


Each  goal  was  tied  to  an  FSM  which  contained  actions  that  were  suitable  to  various  possible 
states  of  the  agent  [21,  p.  11].  In  an  effort  to  make  the  agent’s  behavior  as  realistic  as 
possible,  these  plans  typically  contained  conditional  branches  that  were  used  to  select  the 
action  most  suitable  to  the  situation  [22].  Which  branch  was  selected  was  dependent  upon 
the  agent’s  state  and  the  preconditions  for  each  FSM  node.  While  this  approach  produced 
unique  behavior  properties  for  NOFF2  agents,  limitations  were  still  encountered. 

First,  “a  problem  with  the  hard  coded  FSM  in  NOFF2  is  that  goals  cannot  communicate 
with  each  other”  [21,  p.  11].  This  lack  of  communication  resulted  in  the  appearance  of 
awkward  behaviors  when  agents  transitioned  from  one  goal  to  another.  NOFF2  also  exhib¬ 
ited  many  of  the  previously  described  problems  attributed  to  FSMs. 

When  creating  variations  in  agent  behaviors,  branches  had  to  be  added  to  existing  state 
machines.  According  to  one  NOFF2  programmer,  after  “two  years  of  development,  these 
state  machines  became  overly  complex,  bloated,  unmanageable,  and  a  risk  to  the  stability 
of  the  project”  [1 1,  p.  7].  This  meant  that  behavior  limitations  had  to  be  accepted  in  order  to 
prevent  the  FSMs  from  growing  too  complex.  Additionally,  it  was  risky  to  alter  the  FSMs 
late  in  the  development  cycle.  Despite  these  issues,  NOFF2  represented  an  important  step 
in  a  new  direction.  The  work  done  on  this  game  led  AI  designers  to  the  realization  that 
separating  an  agent’s  goal  from  the  plan  that  was  used  to  accomplish  the  goal  would  offer 
a  revolutionary  new  way  for  creating  automated  behaviors. 
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2.2  Classical  Planning  Techniques 

As  demand  for  more  realistic  automated  behaviors  increased,  problems  with  legacy  pro¬ 
gramming  techniques  became  more  apparent.  Planning  techniques  such  as  the  Stanford 
Research  Institute  Problem  Solver  (STRIPS),  goal-oriented  action  planning  (GOAP),  and 
HTN  planning,  offer  a  different  approach  to  producing  automated  behaviors.  Some  of  these 
planning  techniques  have  made  a  substantial  impact  in  areas  such  as  the  robotics  industry. 
However,  it  is  not  until  recently  that  they  began  to  play  a  part  in  the  simulation  and  gaming 
realms. 

2.2.1  Stanford  Research  Institute  Problem  Solver 

The  STRIPS  concept  was  introduced  by  Fikes  and  Nilsson  in  their  1971  landmark  work, 
“STRIPS:  A  New  Approach  to  the  Application  of  Theorem  Proving  to  Problem  Solving.” 
As  described  by  AI  programmer  Jeff  Orkin,  STRIPS  “consists  of  goals  and  actions,  where 
goals  describe  some  desired  state  of  the  world  we  want  to  reach,  and  actions  are  defined  in 
terms  of  preconditions  and  effects”  [11,  p.  4].  The  STRIPS  algorithm  includes  several  key 
concepts.  First,  the  AI  decision  making  takes  place  in  planning  space  as  opposed  to  state 
space.  This  means  that  a  plan  is  constructed  before  any  actions  are  taken.  This  is  different 
from  FSMs  and  behavior  trees  which  make  decisions  during  real  time.  Second,  a  STRIPS 
planning  problem  consists  of  three  main  components:  initial  state,  goal,  and  available  ac¬ 
tions  [23,  p.  18].  These  three  inputs  are  used  as  factors  in  a  search  which  determines  the 
ideal  action  for  an  agent  to  perform.  This  differs  from  behavior  trees  for  which  no  search 
is  required;  “the  behavior  tree  is  traversed  as  a  kind  of  pre-defined  program”  [10,  p.  22]. 

2.2.2  Goal-Oriented  Action  Planning  Overview 

One  of  the  first  viable  alternatives  to  FSM  and  goal  tree  based  techniques  was  introduced 
in  the  2004  game  First  Encounter  Assault  Recon  (F.E.A.R.).  The  success  of  F.E.A.R.  was 
largely  due  to  its  use  of  a  modified  form  of  STRIPS  planning  known  as  GOAP.  GOAP  is 
a  dynamic  behavior  planning  technique  that  was  devised  to  overcome  many  of  the  short¬ 
comings  of  FSMs  and  behavior  trees.  The  purpose  of  GOAP  is  to  create  agents  which 
are  able  to  execute  actions  that  are  appropriate  to  their  current  state.  The  major  difference 
between  GOAP  and  reactive  planning  methods  is  that  GOAP  goals  are  not  linked  to  a  pre- 
established  plan.  According  to  Jeff  Orkin,  “a  planning  system  tells  the  AI  what  his  goals 
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and  actions  are,  and  lets  the  AI  decide  how  to  sequence  actions  to  satisfy  goals.  FSMs  are 
procedural,  while  planning  is  declarative”  [11,  p.  3].  Through  the  use  of  such  an  automated 
planner,  unique  actions  are  produced  each  time  an  agent  is  assigned  a  goal. 

An  unorthodox  use  of  the  A-star  (A*)  search  method  is  the  first  key  to  the  creation  of  an 
automated  planner.  A*  is  a  technique  which  is  normally  associated  with  determining  a 
navigation  path,  however,  it  is  actually  a  general  purpose  graph  traversal  algorithm  which 
can  be  utilized  for  many  purposes.  As  stated  by  Jeff  Orkin,  “in  the  case  of  planning,  the 
nodes  are  states  of  the  world,  and  we  are  searching  to  find  a  path  to  the  goal  state.  The 
edges  connecting  different  states  of  the  world  are  the  actions  that  lead  the  state  of  the  world 
to  change  from  one  to  another”  [11,  p.  11].  Typical  GOAP-type  games  will  utilize  A* 
for  both  planning  and  navigational  purposes.  Figure  2.7  illustrates  the  inputs  for  an  A* 
program  when  it  is  used  for  different  purposes.  This  is  a  technique  that  has  the  potential  to 
produce  realistic  plans  which  are  uniquely  tailored  to  an  agent’s  specific  circumstances. 

2.2.3  Case  Study:  First  Encounter  Assault  Recon 

As  the  first  game  to  implement  the  GOAP  approach,  F.E.A.R.  represented  a  revolution  in 
the  creation  of  automated  tactical  behaviors.  In  the  following  quote,  programmer  Jeff  Orkin 
describes  how  the  use  of  GOAP  provided  significant  advantages  to  game  developers. 


Late  in  development  of  NOLF2,  we  added  the  requirement  that  AI  would  turn 
on  lights  whenever  entering  a  dark  room.  In  our  old  system,  this  required 
us  to  revisit  the  state  machine  inside  every  goal,  and  figure  out  how  to  insert 
this  behavior.  This  was  both  a  headache,  and  a  risky  thing  to  do  so  late  in 
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Figure  2.7:  A*  Algorithm  for  Navigation  and  Planning,  from  [11] 
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development.  With  the  F.E.A.R.  planning  system,  adding  this  behavior  would 
have  been  much  easier,  as  we  could  have  just  added  a  TumOnLights  actions 
with  a  LightsOn  effect,  and  added  a  LightsOn  precondition  to  the  Goto  action. 
[11,  p.  10] 


First  Encounter  Assault  Recon  Overview 

The  success  of  F.E.A.R.  was  achieved  through  hard  work,  and  a  unique  perspective  on  many 
traditional  gaming  techniques.  The  first  significant  departure  from  most  gaming  systems 
can  be  found  in  the  F.E.A.R.  FSM  which  includes  only  three  states:  Goto,  Animate,  and 
UseSmartObject.  GoTo  involves  an  agent  moving  to  a  new  location,  Animate  describes  an 
action  that  an  agent  takes  (such  as  shooting),  and  UseSmartObject  is  a  specialized  version 
of  Animate  [11,  p.  2],  All  AI  actions  in  F.E.A.R.  can  be  categorized  using  these  three  states. 
For  example,  “an  AI  going  for  cover  is  just  moving  to  some  position,  and  then  playing  a 
duck  or  lean  animation”  [1 1,  p.  2]. 

The  difficulty  in  this  system  arises  when  determining  when  an  agent  should  transition  from 
one  state  to  another.  In  traditional  reactive  planning  techniques,  this  transition  has  either 
been  scripted,  or  written  into  the  FSM  states.  In  F.E.A.R.  this  transition  logic  was  imple¬ 
mented  into  the  planning  system. 

The  planning  system  connects  to  the  FSM  by  designating  a  chain  of  actions  to  accomplish, 
and  then  by  activating  these  actions  at  appropriate  times.  Jeff  Orkin  states  that  “when  we 
execute  our  plan,  we  sequentially  activate  our  actions,  which  in  turn  set  the  current  state, 
and  any  associated  parameters.  The  code  inside  the  ActivateAction()  function  sets  the  AI 
into  some  state,  and  sets  some  parameters.  For  example,  the  Flee  action  sets  the  AI  into  the 
Goto  state,  and  sets  some  specific  destination  to  run  to.”  [11,  pp.  12-13]. 

While  the  F.E.A.R.  planning  system  is  based  on  STRIPS,  several  key  adjustments  were 
necessary  in  order  to  ensure  the  system  was  suitable  for  a  gaming  environment.  Major 
differences  included  adding  a  cost  per  action,  eliminating  Add  and  Delete  Lists  for  effects, 
and  adding  procedural  preconditions  and  effects  [11,  p.  2].  These  adjustments  were  made 
for  several  reasons. 

•  Assigning  costs  to  actions  enables  the  A*  based  planner  to  search  for  “the  lowest  cost 
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sequence  of  actions  [that]  satisfy  some  goal”  [11,  p.  11]. 

•  Replacing  Add  and  Delete  Lists  with  a  fixed-sized  array  representing  the  world  state 
“makes  it  trivial  to  find  the  action  that  will  have  an  effect  that  satisfies  some  goal  or 
precondition”  [11,  pp.  11-12]. 

•  Procedural  Preconditions  were  added  in  order  to  optimize  system  functionality.  Jeff 
Orkin  states  that  “it  would  be  impractical  to  always  keep  track  of  whether  an  es¬ 
cape  path  exists  in  our  world  state,  because  pathfinding  is  expensive.  The  Procedural 
Preconditions  function  allows  us  to  do  checks  like  this  on-demand  only  when  neces¬ 
sary”  [11,  p.  12], 

•  Procedural  Effects  are  important  for  linking  changes  in  the  world  state  to  the  actions 
that  are  carried  out.  “We  don’t  want  to  simply  directly  apply  the  effects  that  we’ve 
represented  as  world  state  variables,  because  that  would  indicate  that  changes  are 
instantaneous.  In  reality  it  takes  some  amount  of  time  to  move  to  a  destination,  or 
eliminate  a  threat”  [11,  p.  12].  This  is  important  because  while  an  action  is  being 
carried  out  in  a  dynamic  environment,  the  state  of  the  world  can  change  for  reasons 
having  nothing  to  do  with  the  procedure  being  executed. 

Goal- Oriented  Action  Planning  Benefits 

This  planning  system’s  first  major  contribution  was  the  separation  of  goals  and  actions. 
Unlike  in  previous  systems,  F.E.A.R.  developers  could  make  changes  to  the  system  when 
they  were  well  into  the  development  process.  One  example  of  this  included  adding  a  new 
character  to  the  game.  The  modular  nature  of  the  system  enabled  developers  to  combine 
previously  created  goals  and  actions,  and  ultimately  create  a  “unique  new  enemy  type  in  a 
minimal  amount  of  time,  without  imposing  any  risk  on  existing  characters”  [11,  p.  8]. 

According  to  Jeff  Orkin,  “decoupling  the  goals  and  actions  forces  them  to  share  information 
through  some  external  working  space.  In  a  decoupled  system,  all  goals  and  actions  have 
access  to  information...  We  can  take  this  knowledge  into  account  when  we  formulate  a 
plan  to  satisfy”  a  specific  goal  [11,  p.  8].  This  information  enabled  the  system  to  devise  a 
more  intelligent  plan.  It  also  prevented  the  appearance  of  awkward  behaviors  observed  in 
previous  systems,  when  agents  transitioned  from  one  goal  to  another.  [11,  p.  8].  Figure  2.8 
depicts  the  organization  of  goals  and  behaviors  in  F.E.A.R.  This  organization  is  in  stark 
contrast  to  NOFF2  which  linked  goals  to  FSMs. 
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Figure  2.8:  Comparison  of  Behaviors  in  No  One  Lives  Forever  2  and  First  Encounter  Assault 
Recon,  from  [11] 


“The  second  benefit  of  the  planning  approach  is  facilitating  the  layering  of  behaviors”  [11, 
p.  8].  This  attribute  enabled  developers  to  create  interesting  agent  behaviors  which  ranged 
from  simple  movement  techniques  to  more  complex  tactical  procedures.  The  real  benefit 
of  this  ability  was  that  actions  could  be  added  without  adversely  affecting  other  behaviors. 
The  quote  at  the  beginning  of  this  section  which  discussed  adding  a  "TurnOnLights"  action 
is  an  example  of  this.  Figure  2.9  lists  some  of  the  behaviors  assigned  to  various  characters 
in  F.E.A.R.  The  planning  system  could  choose  from  these  behaviors  when  attempting  to 
accomplish  a  specific  goal. 

The  final  benefit  of  planning  has  to  do  with  the  emergence  of  dynamic  behavior.  A  common 
axiom  among  military  professionals  is  that  the  best  laid  plans  are  often  nullified  as  soon  as 
enemy  contact  is  made.  This  saying  is  not  only  applicable  to  real  life,  but  also  to  simulations 
and  games.  When  an  agent  recognizes  that  it  has  failed  to  execute  a  task,  the  agent’s  current 
plan  becomes  irrelevant,  and  the  agent  uses  the  planning  system  to  determine  a  new  course 
of  action.  According  to  Jeff  Orkin,  “dynamic  behavior  arises  out  of  re-planning  while 
taking  into  account  knowledge  gained  through  previous  failures...  As  the  AI  discovers 
obstacles  that  invalidate  his  plan...  he  can  record  this  knowledge  in  working  memory,  and 
take  it  into  consideration  when  re-planning  to  find  alternative  solutions  to”  his  goal  [1 1,  p. 
10]. 

These  attributes  were  instrumental  in  allowing  individual  entities  within  F.E.A.R.  to  carry 


22 


1 13 

Soldier 

T 

Assassin 

fc2l’r  1 

Rat 

B 

Action 

□  Action 

B  Action 

1 

AI/Actions/  Attack 

1  AI/Actions/Attack 

1  AI/Actions/ Animate 

2 

AI/ Ac  t  ions/ At  t  at  k  C  roue  h 

2  AI/Actions/InspectDisturbance 

2  AI/Actions  .Idle 

3 

AI/Actions /SuppressionFire 

3  AI/Actions/LookAtDisturbance 

3  AI/Actions/GotoNode 

4 

AI / Actions  SuppressionFireFromCover 

4  AI/ Act  ions/Survey  Area 

4  AI/Actions/UseSmartObjectNode 

5 

AI/ Actions /FlushOut  Wit  hGrenade 

5  AI/Actions/AttackMeleeUncloaked 

+ 

6 

AI/Actions  AttaekFromCover 

6  AI/Actions/TraverseBlockedDoor 

7 

AI  /Actions  BlindFireFromC  over 

7  AI/Actions/UseSmartObJectNodeMounted 

8 

AI  / Actions  AttackGrenadeFromCover 

8  AI/Actions/MountNodeUndoaked 

9 

AI/Actions/AttackFromView 

9  AI/Actions.  Dismount NodeUndoaked 

10 

AI/  Actions /Dr  awWeapon 

10  AI/Actions/TraverseLinkUndoaked 

11 

AI/ Act  ions /Holster  Weapon 

11  AI/Actions/AttackFromAmbush 

12 

AI  /  Ac  t  ions/R  eloadC  roue  h 

12  AI/Actions/DodgeRoMParanoid 

13 

AI/Actions/ReloadCovered 

1 3  AI/ Ac t  ions/ At  t  ac  k  L  ungeUnc  loaked 

14 

AI/Actions /Inspec  tDist  urbane  e 

14  AI/Actions/lopeToTargetUncloaked 

15 

AI/ Actions  ’Look  At  Disturbance 

+ 

16 

AI/Actions  SurveyArea 

17 

AI/ Actions  DodqeRoll 

18 

AI /Actions  DodqeShuffle 

19 

AI  /  Act  ions  / DodqeCovered 

20 

AI/Actions/Uncover 

21 

AI/Actions /AttackMelee 

Figure  2.9:  Example  Actions  used  in  First  Encounter  Assault  Recon,  from  [11] 


out  realistic  actions  which  suited  their  current  situation.  In  the  following  quote,  Jeff  Orkin 
describes  how  the  game  structure  limited  some  of  the  problems  associated  with  reactive 
planning  techniques,  and  allowed  developers  to  focus  their  efforts  on  other  areas: 


The  design  philosophy  at  Monolith  is  that  the  designer’s  job  is  to  create  in¬ 
teresting  spaces  for  combat,  packed  with  opportunities  for  the  AI  to  exploit. 

For  example,  spaces  filled  with  furniture  for  cover,  glass  windows  to  dive 
through,  and  multiple  entries  for  flanking...  This  means  that  the  AI  need  to 
autonomously  use  the  environment  to  satisfy  their  goals.  [11,  p.  6] 

Squad  Behaviors 

The  last  innovation  included  in  F.E.A.R.  was  an  ability  for  automated  agents  to  coordinate 
their  actions  in  a  realistic  fashion.  By  periodically  grouping  nearby  agents  into  a  squad,  the 
system  gained  the  ability  to  implement  one  of  four  squad  behaviors  [11,  p.  13]: 
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Get-to-Cover:  gets  all  squad  members  who  are  not  currently  in  valid  cover  into  valid 
cover,  while  one  squad  member  lays  suppression  fire 
Advance-Cover:  moves  members  of  a  squad  to  valid  cover  closer  to  the  threat,  while  one 
squad  member  lays  suppression  fire 

Orderly- Advance:  moves  a  squad  to  some  position  in  a  single  file  line,  where  each  AI 
covers  the  one  in  front,  and  the  last  AI  faces  backward  to  cover  from  behind 
Search:  splits  the  squad  into  pairs  who  cover  each  other  as  they  systematically  search 
rooms  in  some  area 

The  mechanism  for  creating  the  squad  behavior  was  a  non-STRIPS  system  that  was  sepa¬ 
rate  from  the  planner  used  to  construct  individual  behaviors  [11,  p.  15].  This  process  was 
accomplished  in  the  following  manner: 


First,  the  squad  behavior  tries  to  find  AI  that  can  fill  required  slots.  If  it  finds 
participants,  the  squad  behavior  activates  and  sends  orders  to  squad  members. 
AI  have  goals  to  respond  to  orders,  and  it  is  up  to  the  AI  to  prioritize  following 
those  orders  versus  satisfying  other  goals.  For  example,  fleeing  from  danger 
may  trump  following  an  order  to  advance.  The  behavior  then  monitors  the 
progress  of  the  AI  each  clock  tick.  [1 1,  p.  13] 


The  combination  of  the  squad  and  individual  behavior  control  mechanisms  produced  a 
unique  type  of  automated  tactical  behavior  in  F.E.A.R.  One  of  the  key  reasons  for  this 
is  an  individual  agent’s  ability  to  override  a  squad  order  that  does  not  make  sense  due 
to  the  agent’s  current  state.  Though  such  a  decision  may  cause  the  squad  behavior  to 
fail,  it  often  resulted  in  the  emergence  of  more  complex  tactical  behaviors  which  software 
developers  never  programmed  into  the  system.  Examples  of  these  behaviors  show  strong 
similarities  to  military  tactics  such  as  fix  and  flank  maneuvers,  double  envelopments,  and 
withdrawals  under  pressure.  According  to  game  designers,  the  primary  reason  for  this 
emergent  behavior  was  due  to  the  separation  of  the  individual  and  squad  level  planning 
systems  [11,  p.  15]. 

The  use  of  GOAP  in  F.E.A.R.  served  to  illustrate  a  revolutionary  new  way  of  controlling 
automated  behaviors.  Unfortunately,  this  method  appears  to  be  limited  in  capabilities.  The 
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emergent  behaviors  described  above  mostly  included  very  small  numbers  of  automated 
characters.  One  of  the  reasons  for  this  is  that  for  GOAP  “to  formulate  a  plan,  the  planner 
must  be  able  to  represent  the  state  of  the  world  in  a  compact  and  concise  form”  [22]. 
Through  much  hard  work,  the  developers  of  F.E.A.R.  were  able  to  accomplish  such  a  task. 
The  use  of  an  FSM  with  only  three  states  played  a  vital  role  in  their  success.  However,  large 
numbers  of  agents  and  inherent  complexity  of  simulations  limit  the  ability  to  expand  upon 
the  techniques  used  in  F.E.A.R.  This  has  led  to  the  emergence  of  a  new  type  of  planning 
system. 


2.3  Hierarchical  Task  Network  Planning 

The  topic  of  automated  planning  is  an  important  area  of  research  within  the  computer  sci¬ 
ence  realm.  Much  work  is  devoted  to  producing  newer  and  more  optimal  planning  models. 
Numerous  methods  exist,  each  with  their  own  advantages  and  disadvantages.  One  such  so¬ 
lution,  HTN  planning,  is  of  interest  to  this  work  because  it  is  a  type  of  automated  planning 
that  is  still  evolving.  In  the  following  statement,  Jeff  Orkin  describes  how  HTN  planning 
could  advance  the  capabilities  demonstrated  in  F.E.A.R. 


A  logical  next  step  from  what  we  did  for  F.E.A.R.  would  be  to  apply  a  for¬ 
malized  planning  system  to  the  squad  behaviors.  A  developer  interested  in 
planning  for  squads  may  want  to  look  at  HTN  planning,  which  facilitates  plan¬ 
ning  actions  that  occur  in  parallel  better  than  STRIPS  planning.  Planning  for 
a  squad  of  AI  will  require  planning  multiple  actions  that  run  in  parallel.  HTN 
planning  techniques  have  been  successfully  applied  to  the  coordination  of  Un¬ 
real  Tournament  bots.  [11,  p.  15] 

2.3.1  Hierarchical  Task  Network  Overview 

First  introduced  as  “procedural  nets”  in  1975  by  Sacerdoti,  HTN  planning  has  been  applied 
to  many  domains  because  of  advantages  it  possesses  in  efficiency,  scalability,  and  reusabil¬ 
ity  [24].  According  to  Imre  Balogh,  “the  idea  behind  the  HTN  methodology  is  to  have  a 
way  to  represent  many  overlapping  plans  within  a  single  structure  that  can  be  used  to  gen¬ 
erate  a  specific  plan  based  on  the  state  of  the  world  at  the  time  the  plan  is  generated”  [25]. 
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As  stated  by  Dana  Nau,  “the  objective  of  an  HTN  planner  is  to  produce  a  sequence  of  ac¬ 
tions  that  perform  some  activity  or  task  [26,  p.  380].”  Figure  2.10  depicts  an  example  HTN 
behavior.  HTN  tasks  are  generally  grouped  into  the  following  three  categories  [25]: 

1 .  Goal  Tasks  -  tasks  that,  when  completed,  correspond  to  the  goal  of  the  network/tree 

2.  Compound  Tasks  -  tasks  that  need  to  be  decomposed  into  sets  of  simpler  tasks 

3.  Primitive  Tasks  -  tasks  that  require  no  further  decomposition  to  be  performed  and 
can  be  directly  executed 

Task  decomposition  is  the  primary  method  through  which  HTNs  function;  creating  an  HTN 
is  generally  accomplished  through  the  following  decomposition  process.  The  first  step  is 
to  identify  a  high  level  task  to  be  accomplished,  and  to  define  a  goal  state  which  represents 
the  system  state  upon  completion  of  the  high  level  task.  The  second  step  involves  problem 
decomposition  in  which  one  must  identify  sub-tasks  that  are  necessary  to  reach  the  goal 
state.  The  final  step  involves  determining  whether  each  sub-task  represents  a  primitive 
task,  or  a  complex  task.  This  process  is  repeated  until  all  complex  tasks  are  reduced  to 
primitive  tasks. 

One  of  the  key  advantages  of  HTNs  is  that  they  can  contain  numerous  paths  for  reaching 
a  single  goal  state.  Path  selection  is  accomplished  through  two  key  processes.  First,  the 
ordering  of  the  nodes  controls  the  priority  given  to  different  paths  (if  more  than  one  is  possi¬ 
ble).  Second,  constraint  nodes  require  preconditions  to  be  met  before  a  path  is  undertaken; 
this  serves  to  provide  a  mechanism  through  which  the  context  affects  the  plan.  These  im¬ 
portant  HTN  attributes  enable  an  agent  facing  a  decision  point  to  “select”  the  solution  that 


Figure  2.10:  Example  of  Hierarchical  Task  Network  Task  Decomposition,  from  [25] 
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is  most  appropriate  to  its  current  situation.  In  conjunction  with  properties  including  effi¬ 
ciency,  reusability,  and  scalability,  this  example  of  automated  planning  establishes  HTNs  as 
a  tool  which  could  greatly  improve  the  effectiveness  of  many  programs,  including  military 
simulations. 

2.3.2  Simple  Hierarchical  Ordered  Planner 

These  attributes  made  HTNs  extremely  popular  for  many  planning  problems,  and  within 
domains  such  as  production-line  scheduling,  crisis  management,  logistics,  equipment  con¬ 
figuration,  manufacturability  analysis,  and  evacuation  planning  [26,  p.  395].  Many  ad¬ 
vances  in  HTN  usage  have  been  made  by  Professor  Dana  Nau  and  his  colleagues  at  the 
University  of  Maryland.  They  are  the  creators  of  the  award  winning  Simple  Hierarchical 
Ordered  Planner  (SHOP). 

SHOP  includes  a  family  of  HTN  planners  which  earned  acclaim  for  their  ability  to  gener¬ 
ate  strategies  in  the  game  Bridge.  The  performance  of  many  planning  systems  are  often 
negatively  impacted  by  large  search  spaces.  SHOP  offers  a  solution  to  this  problem.  For 
the  Bridge  problem,  the  original  SHOP  HTN  planner  conducted  a  search  to  determine 
a  player’s  best  possible  move.  However,  instead  of  initially  considering  every  potential 
move,  the  HTN  first  determined  a  general  Bridge  strategy  to  pursue.  [27].  This  process  of 
designating  general  strategies,  as  opposed  to  designating  specific  actions,  had  the  effect  of 
creating  smaller  search  spaces  than  those  seen  in  conventional  planners  such  as  STRIPS. 

This  illustrates  a  major  difference  between  HTN  planning  and  behavior  trees.  HTN  plan¬ 
ners  specify  the  world  state  that  corresponds  to  a  goal,  simulate  numerous  plans  for  reach¬ 
ing  that  world  state,  and  then  speculate  which  plan  is  best.  This  final  plan  is  executed 
by  the  player.  This  sequence  differs  from  behavior  trees  which  perform  actions  in  real 
time,  and  apply  changes  directly  to  the  world  state  [27].  HTN  planning  also  possesses 
many  distinctions  from  other  planning  techniques.  One  of  the  problems  with  some  conven¬ 
tional  planners  is  that  when  creating  plans,  they  may  not  link  actions  together  in  the  correct 
order  [27].  Because  subject  matter  experts  construct  hierarchical  plans  which  accurately 
represent  actions  within  their  domain,  HTN  planning  can  minimize  this  problem. 

The  success  of  SHOP  encouraged  Professor  Nau  and  his  associates  to  continue  their  work 
with  HTNs.  Simple  Hierarchical  Ordered  Planning  2  (SHOP2)  is  a  domain- independent 
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program  that  contains  many  improvements  over  the  original  SHOP,  and  allows  users  to 
utilize  HTNs  in  new  ways  [26,  p.  379].  The  first  improvement  concerns  the  way  that  tasks 
are  ordered.  The  order  in  which  potential  tasks  are  specified  is  also  the  order  in  which 
the  planner  will  consider  each  task.  While  advantageous  from  the  perspective  of  allowing 
the  programmer  to  tailor  the  planner’s  decision  making,  not  all  situations  should  have  their 
potential  tasks  considered  in  the  same  order.  SHOP2  offers  “a  convenient  way  for  the  author 
of  a  planning  domain  to  tell  SHOP2  which  parts  of  the  search  space  to  explore  first”  [26,  p. 
380].  The  SHOP2  method  of  “partial  ordering”  enables  the  planner  to  interleave  subtasks 
from  different  tasks,  and  ultimately  “makes  it  possible  to  specify  domain  knowledge  in 
a  more  intuitive  manner  than  was  possible  with  SHOP”  [26,  p.  380].  Finally,  SHOP2 
incorporates  several  features  such  as  quantifiers  and  conditional  effects  from  the  Planning 
Domain  Definition  Language  (PDDL)  which  was  created  in  an  effort  to  standardize  AI 
techniques. 

One  additional  program  of  note  is  Pyhop.  Developed  by  Dr.  Nau  and  his  associates,  Pyhop 
is  an  HTN  planner  that  is  written  in  the  Python  language.  While  its  planning  algorithm 
bares  many  similarities  to  that  of  SHOP,  several  differences  exist.  One  such  difference  is 
that  HTN  operators  and  methods  are  represented  by  Python  functions  [28].  As  open-source 
software  that  is  relatively  easy  to  understand  and  implement,  Pyhop  provides  an  excellent 
way  to  leam  more  about  HTN  functionality. 

2.3.3  Planning  in  Dynamic  Environments 

As  the  capabilities  of  HTNs  expanded,  researchers  began  applying  HTNs  to  new  domains. 
The  first  person  shooter  (FPS)  game  Unreal  Tournament  showcased  one  of  the  first  uses  of 
HTNs  in  the  gaming  industry.  In  this  example,  HTN  planning  was  used  to  create  an  overall 
strategy  for  AI  controlled  teams,  and  to  assign  specific  tasks  to  individual  entities  within 
those  teams.  By  retaining  the  event-driven  nature  of  individual  entities,  this  technique 
allowed  entities  to  “react  to  the  [dynamic]  events  in  the  environment  while  contributing  to 
[their  team’s]  grand  strategy”  [8,  p.  1].  While  this  effort  provided  numerous  advantages 
over  previous  AI  techniques,  the  integration  of  HTNs  into  video  games  was  not  without 
difficulties. 

Despite  its  success  in  many  domains,  HTN  pioneer  Dana  Nau  was  surprised  with  the  use 
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of  HTN  planning  systems  in  the  gaming  realm  [27].  One  of  the  major  reasons  for  this  is 
that  HTNs  were  designed  to  be  run  and  employed  in  a  static  environment.  This  presents  a 
problem  in  the  gaming  and  simulation  domains  where  constantly  changing  environments 
can  invalidate  an  agent’s  plan  for  achieving  a  stated  goal.  In  the  Unreal  Tournament  ex¬ 
ample,  event  handlers  were  “used  to  detect  relevant  events  that  [might]  require  interrupting 
the  current  action  being  executed  to  select  a  new  one.  For  example,  while  performing  the 
exploring  action,  the  Bot  may  interrupt  the  explore  action  and  start  a  hunting  action  if  it 
detects  an  enemy  in  the  surrounding  area”  [8,  p.  2].  Another  way  this  issue  can  be  dealt 
with  is  by  repeating  the  HTN  planning  process,  or  replanning,  at  a  specified  time  interval. 
This  technique  has  been  used  in  gaming  applications  where  there  exist  a  limited  number 
of  entities.  However,  because  the  planning  process  is  potentially  expensive,  this  technique 
will  not  work  for  many  types  of  simulations  which  contain  hundreds  or  even  thousands  of 
entities. 

One  current  method  for  minimizing  this  problem  involves  placing  a  mechanism  within  the 
HTN  that  automatically  initiates  replanning.  This  is  accomplished  in  two  ways.  First, 
selected  tasks  within  an  HTN  are  designated  as  replanning  nodes.  Second,  primitive  HTN 
tasks  which  fail  in  execution  are  designed  to  trigger  a  replanning  event  [25,  p.  4].  The 
advantage  of  this  approach  is  that  it  places  “the  burden  of  deciding  when  replanning  should 
occur  on  the  person  creating  the  HTN”  [25,  p.  3]. 

Another  method  of  increasing  the  efficiency  of  HTN  planners  is  through  “lazy  expansion.” 
This  is  a  technique  which  halts  the  execution  of  an  HTN  planner  before  it  creates  a  complete 
plan  capable  of  achieving  some  goal  state.  Elements  of  the  robotics  industry  accomplish 
this  by  employing  “rolling  horizons”  within  planning  algorithms  [27].  Another  way  to  em¬ 
ploy  lazy  expansion  of  HTNs  is  through  the  addition  of  sub-goals  known  as  interrupt  goal 
nodes.  These  mechanisms  are  used  to  “represent  tasks  that  take  some  time  to  complete... 
[and]  to  limit  how  far  ahead  task  related  events  are  scheduled”  [25,  p.  4].  This  technique 
is  uniquely  suited  to  military  simulations  and  games  in  which  conflict  between  opposing 
forces  will  almost  always  force  the  modification  of  battle  plans. 

Each  of  these  techniques  provides  software  developers  valuable  tools  for  controlling  the 
behavior  of  automated  forces.  Methods  for  triggering  replanning  are  likely  to  increase 
realism  of  an  entity’s  behavior.  However,  unnecessary  replanning  events  can  adversely 
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impact  system  performance,  particularly  for  those  simulations  with  a  large  number  of  auto¬ 
mated  forces.  Similarly,  utilizing  the  lazy  expansion  concept  for  HTNs  holds  the  promise 
of  increasing  system  performance,  but  could  affect  a  plan’s  suitability.  In  situations  where 
it  is  important  to  ensure  that  optimal  plans  are  selected,  HTN  planners  may  need  to  look 
further  into  the  future  than  interrupt  nodes  or  rolling  horizons  allow  [27].  Choosing  the  best 
technique  to  employ  depends  heavily  upon  the  characteristics  of  the  intended  simulation  or 
game. 
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CHAPTER  3: 

Dynamic  Behavior  in  Current  Applications 


Chapter  2  discusses  the  history  of  how  automated  behavior  techniques  developed.  It  pro¬ 
vides  important  examples  of  successful  and  unsuccessful  efforts  to  create  automated  human 
behavior.  Understanding  these  examples  can  help  simulation  developers  create  applications 
which  are  able  to  adequately  represent  desired  behaviors. 

At  the  time  of  this  writing,  the  following  examples  represent  some  of  the  most  advanced  ex¬ 
amples  of  automated  behavior  techniques  within  the  gaming  industry.  These  applications 
include  an  FPS  game,  a  military  mission  planning  program,  a  real  time  strategy  (RTS) 
game,  and  a  military  behavior  composition  language.  While  the  appearances  of  these  sys¬ 
tems  are  drastically  different,  they  all  possess  powerful  AI  capabilities.  FPS  and  RTS 
systems  have  been  described  as  working  toward  the  same  goal,  but  from  different  direc¬ 
tions  [29,  p.  75].  For  those  persons  interested  in  advancing  current  combat  simulation 
capabilities,  the  techniques  and  capabilities  of  these  systems  should  be  of  great  interest. 

3.1  Killzone  2 

Killzone  2  is  an  FPS  application  that  was  created  by  Guerilla  Games  and  released  in  2009. 
Killzone  2  was  highly  acclaimed  upon  its  release;  one  of  the  reasons  for  this  was  the  re¬ 
alistic  behavior  of  its  automated  entities.  In  most  FPS  games,  automated  characters  are 
expected  to  exhibit  good  reactive  behaviors,  but  are  not  usually  charged  with  the  accom¬ 
plishment  of  long  term  objectives.  As  demand  for  realistic  automated  behaviors  increased, 
many  individuals  in  the  gaming  industry  found  this  technique  to  produce  inadequate  re¬ 
sults.  The  success  of  Killzone  2  can  be  largely  attributed  to  the  use  of  an  HTN  planner  that 
created  realistic  battle  plans  for  squads  of  automated  characters. 

3.1.1  Hierarchical  Task  Network  Planning 

Killzone  2  was  one  of  the  first  games  to  use  a  complete  HTN  implementation.  Utilizing  one 
of  the  main  strengths  of  HTNs,  Killzone  2  employs  “a  goal-driven  approach  by  separating 
what  to  do  and  how  to  do  it”  [29,  p.  30].  The  game’s  HTN  planner  exhibited  the  following 
important  characteristics  [28,  p.  12]: 
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•  Utilized  a  special-purpose  HTN  planner  for  planning  at  the  squad  level 

•  Utilized  method  and  operator  syntax  similar  to  SHOP  and  SHOP2 

•  Quickly  generated  linear  plans  that  were  appropriate  to  static  environments 

•  Replanned  several  times  per  second  to  account  for  dynamic  game  environment 

•  Created  actions  that  appeared  believable  and  consistent  to  human  users;  did  not  at¬ 
tempt  to  create  an  ideal  plan 

An  important  aspect  to  consider  is  that  of  replanning.  A  plan  is  designated  to  have  failed 
if  a  current  task  fails.  It  is  desirable  to  “abort  [a]  current  plan  preemptively  when  a  better 
plan  [becomes]  available,  [or  when  the]  current  plan  is  no  longer  feasible”  [29,  p.  15].  The 
task  of  knowing  in  advance  when  a  plan  is  going  to  fail  is  one  of  the  difficulties  with  HTNs. 
In  Killzone  2,  this  problem  was  avoided  by  replanning  five  times  per  second.  While  this 
technique  worked  in  Killzone  2,  this  is  not  always  possible  in  larger  simulations,  especially 
those  involving  hundreds  or  thousands  of  entities.  Solving  this  issue  is  a  major  hurdle  for 
those  researchers  interested  in  advancing  the  use  of  HTNs. 

3.1.2  Command  Structure 

The  first  item  of  note  was  the  creation  of  a  hierarchical  AI  structure.  As  depicted  in  Fig¬ 
ure  3.1,  Killzone  2  categorizes  its  AI  capabilities  into  Strategy  AI,  Squad  AI,  and  Indi¬ 
vidual  AI.  Within  this  construct,  the  Strategy  AI  gives  orders  to  a  squad,  and  then  the 
squad  provides  feedback  on  whether  or  not  the  order  succeeded.  Squads  give  orders  to  in¬ 
dividuals,  and  individuals  provide  combat  information  as  feedback  to  the  squad.  One  item 
not  depicted  in  Figure  3.1  is  that  individuals  have  the  capability  to  communicate  with  the 
Strategy  AI  [29,  p.  9]. 

This  command  structure  takes  advantage  of  HTN  capabilities,  one  of  which  is  assigning 
missions  to  specific  units  or  entities.  This  is  depicted  in  Figure  3.2.  Standardized  missions 
within  Killzone  2  included  “search  and  destroy,  capture  and  hold,  search  and  retrieve,  as¬ 
sassination,  and  body  count”  [29,  p.  31].  These  missions  are  of  interest  because  of  their 
reusable  and  scalable  attributes.  Within  Killzone  2,  it  was  important  to  be  able  to  assign 
these  missions  to  units  of  different  composition,  and  still  be  able  to  depend  upon  the  unit  to 
act  in  an  intelligent  manner.  Another  important  aspect  of  the  HTN  planner  was  the  ability 
to  assign  missions  to  units  that  were  best  suited  to  that  specific  task. 
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Figure  3.1:  Al  Architecture,  from  [29] 


Figure  3.2:  Squad  Al,  from  [29] 


Squad  &  Bot  Assignment  Algorithm 

1)  Calculate  the  ideal  distribution  of  bots,  then  squads. 

2)  Create  new  squads  if  necessary. 

3)  Remove  extra  squads  if  too  many  assigned  to  any 
objective. 

4)  Pick  an  objective  for  each  squad: 

If  objective  is  active  already,  pick  new  sub-objective 
regularly. 

Otherwise,  assign  the  best  objective  to  each  squad. 

5)  Unassign  bots  if  too  many  for  squad  or  objective. 

6)  Process  all  free  bots  and  assign  them  to  the  best  squad. 


Figure  3.3:  Killzone  2  Task  Organization  Algorithm,  from  [29] 

One  prerequisite  to  this  capability  was  the  need  to  create  tactical  units  that  were  suitable 
for  fulfilling  various  objectives  and  sub-objectives.  Heuristics  involved  in  this  process  in¬ 
cluded  assigning  entities  to  squads  based  on  proximity  to  objectives,  trying  to  respect  the 
desired  squad  size  parameters,  and  keeping  squads  balanced  [29,  p.  39].  This  process  was 
conducted  according  to  the  algorithm  depicted  in  Figure  3.3. 

3.1.3  Additional  Behavior  Techniques 

Within  Killzone  2,  several  more  traditional  Al  techniques  also  fulfill  important  roles.  Kil¬ 
lzone  2  refers  to  the  affordances  described  in  Chapter  2  as  annotations,  and  uses  them  to 
create  areas  of  the  map  that  will  influence  NPC  dynamic  tactical  reasoning.  As  previously 
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mentioned,  when  advanced  behaviors  are  desired,  “AI  scripts  and  their  ‘if-then’  constructs 
are  not  well  suited  to  interpret  and  balance  the  dozens  of  inputs  necessary  to  tailor  a  tactical 
maneuver  to  the  situation  and  terrain  at  hand”  [19].  Killzone  2  takes  a  different  approach 
to  the  use  of  annotations;  some  of  the  considerations  made  to  produce  more  dynamic  be¬ 
haviors  are  shown  in  Figure  3.4.  Typical  uses  for  these  annotations  include  helping  NPCs 
decide  where  to  hide,  regroup,  defend,  or  stage  an  attack.  Figure  3.5  depicts  annotations 
within  a  Killzone  2  map.  Items  of  particular  interest  in  this  scene  include  the  sniper  po¬ 
sitions.  These  annotations  were  placed  to  indicate  “an  approximate  area  where  it  would 
be  good  for  a  sniper  to  operate”  [29].  However  the  annotations  do  not  micromanage  the 
entities.  Instead,  they  give  “snipers  rough  strategic  guidance  while  low  level  AI  determines 
a  sniper’s  detailed  behaviors”  [29]. 

Pathfinding  is  one  final  technique  which  was  instrumental  in  achieving  Killzone  2’s  auto¬ 
mated  behavior.  A  tool  with  roots  that  can  be  traced  back  to  an  A*  search,  pathfinding  was 
an  important  method  for  making  “medium-term  strategic  decisions  in  space”  [29,  p.  62]. 
This  was  accomplished  through  the  use  of  both  low-level  pathfinders  and  high-level  “strate¬ 
gic”  pathfinders.  Additional  advanced  capabilites  in  Killzone  2  enabled  important  features 
that  would  prevent  multiple  squads  from  crowding  into  the  same  location,  and  would  also 
choose  routes  or  objectives  that  were  suitable  to  a  squad’s  characteristics  and  capabilities. 


Figure  3.4:  Advanced  Embedded  Behavior  Considerations,  from  [20] 
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Figure  3.5:  Killzone  2  Manual  Annotations,  from  [30] 


3.1.4  Killzone  2  Summary 

As  stated  by  Killzone  2  programmer  Alex  Champandard,  “strategy  is  more  than  the  sum 
of  its  parts”  [29].  More  than  any  other  quote,  this  statement  best  describes  the  way  that 
Killzone  2  designers  were  able  to  create  an  extremely  high  level  AI.  None  of  the  AI  com¬ 
ponents  they  utilized  were  new  (including  the  HTN  planner);  however,  game  designers 
stated  that  this  was  the  first  time  such  components  were  combined  within  a  single  FPS 
application.  These  techniques  should  be  of  interest  to  those  who  seek  to  improve  upon 
military  simulations. 

3.2  PlannedAssault 

As  video  games  and  military  simulations  have  evolved,  each  system  has  developed  the 
potential  to  display  military  behavior  in  a  highly  realistic  fashion.  Major  achievements 
have  been  made  in  the  ability  to  visualize  the  detailed  actions  of  a  large  number  of  agents; 
however,  the  ability  for  AI  systems  to  devise  complex  and  coordinated  maneuvers  has  gone 
unrealized.  Creating  such  actions  within  simulations  generally  requires  a  great  deal  of 
manual  scripting  by  scenario  designers. 
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Unsatisfied  with  automated  mission  planning  capabilities  in  FPS  games,  a  Killzone  2  de¬ 
veloper  named  William  van  der  Sterren  sought  to  remedy  this  shortfall.  His  program 
“PlannedAssault”  is  a  web-based  mission  planner  for  Bohemia  Interactive’s  Virtual  Bat- 
tlespace  2  (VBS2)  and  Armed  Assault  programs.  PlannedAssault  creates  mission  plans 
that  incorporate  numerous  military  tactical  considerations  including  coordinated  maneu¬ 
vers,  resource  allocation,  event  triggers,  and  event  synchronization. 


3.2.1  Hierarchical  Plan-Space  Planning 

An  experienced  video  game  programmer  and  AI  developer,  William  van  der  Sterren  con¬ 
sidered  numerous  artificial  intelligent  planning  methods  for  PlannedAssault.  Figure  3.6 
illustrates  the  issues  that  were  encountered  with  planning  techniques  that  were  originally 
considered  for  use  in  the  PlannedAssault  program.  Ultimately,  Hierarchical  Plan-Space 
Planning  offered  the  best  solution  for  creating  an  artificially  intelligent  mission  planner. 

Within  this  technique,  a  plan  is  represented  as  a  hierarchy  of  tasks.  At  the  top  of  the  plan 
are  one  or  more  compound  tasks  needed  to  achieve  a  goal.  The  plan  hierarchy  is  created 
when  methods  are  utilized  to  decompose  these  compound  tasks  into  lower-level  compound 
tasks,  and  primitive  tasks.  The  tasks  themselves  describe  “activity,  ordering,  inputs  & 
outputs,  and  costs”  [31].  Many  of  these  tasks  bear  a  strong  resemblance  to  military  actions. 
Examples  include  tactical  tasks  such  as  clear,  occupy,  and  defend,  as  well  as  low-level  unit 
and  individual  tasks  such  as  move,  wait,  load  vehicle,  and  unload  vehicle.  Tasks  are  also 
classified  according  to  various  scope  categories  including  mission,  objective,  team,  tactic, 


Approach,  as  considered  for  a  multi-mill  planning  problem 


Issues 

"Game  Industry"  techniques 

"Academic" 

lanninq  techniques 

(MC) 

Brute  force 

GOAP/A* 

Behavior 

Trees 

Command 

Hierarchy 

STRIPS 

JSHOP 

Constraint 

solving 

Incomplete  Plan 

X 

Plan  may  contain  actions  which  cannot  be  explained 

X 

? 

Picks  first/any  plan  instead  of  "best" 

? 

? 

X 

X 

Synchronizes  actions 

? 

? 

X 

X 

Cannot  explore  multiple  alternatives 

X 

X 

Drowns  in  combinations 

X 

X 

X 

Cannot  brinq  all  facts  into  planner 

X 

X 

Figure  3.6:  AI  Techniques  Considered  During  PlannedAssault  Development,  from  [31] 
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and  unit(s).  Figure  3.7  and  Figure  3.8  illustrate  how  these  concepts  are  connected. 

These  parameters  aid  in  the  establishment  of  a  hierarchical  plan  which  is  representative  of 
actual  military  actions.  Such  a  hierarchical  structure  enables  software  developers  and  users 
to  analyze  the  plan  for  realism,  to  identify  problems  with  the  program,  and  to  more  readily 
implement  solutions.  While  each  of  these  attributes  plays  an  important  role  in  developing 
a  realistic  military  plan,  the  unique  features  of  Hierarchical  Plan-Space  Planning  are  found 
not  in  the  plan’s  structure,  but  instead  in  the  method  of  the  plan’s  creation. 

To  construct  the  previously  described  hierarchy  of  tasks,  PlannedAssault  conducts  a  search 
in  plan-space  as  opposed  to  state-space  [31].  The  significance  of  this  is  that  the  search 
identifies  which  higher  level  tasks  are  best  suited  to  the  situation,  prior  to  determining  lower 
level  tactical  tasks  for  individual  units.  An  advantage  in  efficiency  is  gained  through  this 
technique  because  “higher  level  (abstract)  choices  typically  have  few  options”  [31].  This 
technique  shows  a  strong  resemblance  to  the  SHOP  Bridge  strategy  that  was  described  in 
Chapter  2. 

3.2.2  Technical  Specifications 

The  PlannedAssault  program  provides  a  unique  capability  that  has  not  previously  been 
demonstrated  in  FPS  applications.  In  part,  this  capability  was  made  possible  by  the  follow¬ 
ing  PlannedAssault  technical  specifications: 

•  The  main  loop  consists  of  an  A*  search  that  conducts  a  best-first  analysis  of  mission 
plans. 

•  “Planner  methods  detail  a  plan  by  picking  a  single  abstract  task  and  decomposing  it 
into  sub-tasks  and/or  setting  its  output  values”  [31,  p.  25]. 

•  Heuristics  are  used  to  “estimate  task  and  plan  costs...  [and  advisors]  generate,  filter, 
sort,  and  select  the  best  options  for  tasks”  [31,  p.  14]. 

•  Additional  factors  of  interest  include  task  inputs  and  outputs.  These  are  used  “to 
parameterize  tasks,  to  share  results,  to  act  as  variables  that  need  to  be  grounded,  and 
to  take  in  hints”  [31,  p.  21]. 

•  Typical  PlannedAssault  input  and  output  types  include  “unit,  objective,  area,  avenue 
of  approach,  landing  zone,  and  path”  [31,  p.  21]. 

•  PlannedAssault  uses  plan  duration  as  one  of  its  primary  cost  indicators. 
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scope 

planner  method  responsibility 

task  examples 

mission 

arrange  objectives,  allocate  units  to 
objectives 

mission 

objective 

define  team  activities,  organize  combat  and 
support  units  in  teams 

clear,  occupy,  defend 

team 

execute  tasks  as  a  team,  distributing  the 
work  according  to  roles 

move,  form  up,  attack,  air  land, 
defend,  counter-attack,  para  drop 

tactics 

synchronize  tactical  moves  between  multiple 
units 

formation  ground  attack,  planned  fire 
support,  smoke  screen 

units 

arrange  co-operation  between 
complementary  units 

transported  move 

unit 

define  end-state 

defend  sector,  guard,  close-air-support 

Figure  3.7:  Planner  Methods,  after  [31] 


■  Parent  task  is  decomposed  into  child  tasks 

■  Tasks  may  have  predecessors  and  successors 

■  Tasks  can  be  compound  or  primitive  (unit  tasks  or  operators) 

■  Tasks  have  start  times  and  duration 


Figure  3.8:  Task  Types,  States  and  Relations,  from  [31] 


3.2.3  User  Interface  Description 

The  AI  capabilities  of  PlannedAssault  provide  a  powerful  new  way  to  create  complex  mis¬ 
sions,  however  that  is  not  its  only  attribute.  PlannedAssault  provides  an  intuitive  mission 
creation  interface  which  could  serve  as  a  template  for  military  simulations.  The  entire 
program  is  run  through  the  use  of  a  standard  web  browser.  The  PlannedAssault  user  is 
presented  with  several  initial  choices  including  terrain  and  force  selection.  To  ease  the  de¬ 
velopment  process,  the  user  is  provided  numerous  unit  templates  which  represent  military 
units  and  their  standard  equipment.  Examples  of  these  unit  templates  are  depicted  in  Fig¬ 
ure  3.9.  This  process  serves  as  an  important  step  in  reducing  the  amount  of  time  required 
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Please  select  the  BLUFOR  units  for  your  mission  (maximum  10) 


Available  Units 


US  Marine  Corps  raod:  ArcA  XI  US  M«rin*  Corps  units 

. - ■■  USMC  Rifle  Squad.  12  can  USMC  rifle  squad.  12  cen. 


□r 


. - ■■  USMC  Machine  Gun  Squad.  7  man  USMC  cachir.e  gun  squad.  7  men . 


□  I 

• - is  USMC  Force  Recon  Rifle  Squad.  12  can  USMC  Force  Recon  squad. 

! _ ||  -  -»■ 

| - j  j  USMC  LAR  platoon  dismounts.  18  man  USMC  LAR  dismounts.  IS  men 

□  I 

□  I 

□  I 

□  I 

□  I 

□  V 


LAV-25  KQ  vehicle.  Single  LAV-25  headquarters  vehicle. 
1  vehicles,  2  crew. 


AAVP-7A1  amphibious  assault  vehicle.  Single  AAVP-7A1  amphibious 
assault  vehicle.  1  vehicles,  3  crew,  18  free  seats. 


, - ||  HMWV  TOW  vehicle.  Single  Stt*«V  TOW  anti-tank  vehicle. 

1  1  vehicles,  2  crew,  3  free  seats. 


K 1MTV  section.  Section  of  two  armed  HMMW7  vehicles.  2  vehicles, 
4  crew,  €  free  seats . 


KMMW7  TOW  section.  Section  of  two  KMM5JV  TOW  anti-tank  vehicles . 
vehicles,  4  crew,  €  free  seats. 


Selected  Units  BLUFOR 


□I 

□I 

□I 

□I 

□8 

□I 


ALPHA.  M252  Sima  mortars  section.  Section  of  two  M252  Sima 
mortars,  range  0 . 1km- 3 .7km.  2  guns,  2  crew. 

BRAVO.  USMC  Assault  Team  SKAH.  4  mar.  USMC  assault  squad  SKAW. 

4  men. 

CHARLIE.  USMC  Machine  Gun  Squad.  7  man  USMC  machine  gun  squad. 
7  men. 

DELTA.  USMC  Rifle  Squad.  12  man  USMC  rifle  squad.  12  men. 

ECHO.  USMC  Rifle  Squad.  12  man  USMC  rifle  squad.  12  men. 

FOXTROT.  USMC  Rifle  Squad.  12  man  USMC  rifle  squad.  12  men. 

Drag  a  unit  template  icon  here  to  add  a  new  unit. 

Drag  a  unit  template  icon  here  to  add  a  new  unit. 

Drag  a  unit  template  icon  here  to  add  a  new  unit. 

Drag  a  unit  template  icon  here  to  add  a  new  unit. 


Drag  a  unit  icon  to  one  of  the  above  positions  to  add  or  replace  a 
unit. 


Figure  3.9:  PlannedAssault  Unit  Selection,  from  [32] 


for  scenario  creation. 

Mission  assignment  is  the  second  important  aspect  of  the  PlannedAssault  interface.  Op¬ 
tions  to  choose  from  are  similar  to  doctrinal  military  tasks  for  both  offensive  and  defensive 
operations.  Figure  3.10  illustrates  tasks  that  were  available  at  the  time  of  this  writing.  The 
first  type  of  offensive  task  describes  a  standard  clearing  mission.  Options  for  the  selection 
between  a  one-,  two-,  or  three-pronged  attack  enable  scenario  developers  to  scale  the  width 
of  an  attacking  force’s  frontage.  The  second  type  of  mission  involves  the  combination  of  a 
frontal  and  a  flanking  attack:  a  fundamental  behavior  for  military  units.  Program  features 
enable  the  scenario  developer  to  designate  which  direction  the  flanking  attack  is  to  come 
from,  or  to  let  the  program  make  that  decision. 

While  the  assignment  of  behaviors  to  units  is  of  much  interest  to  this  work,  PlannedAs¬ 
sault  also  includes  several  additional  features  for  creating  a  military  plan.  Once  all  forces 
have  been  constructed  and  their  missions  identified,  the  scenario  designer  designates  each 
unit’s  initial  location,  as  well  as  several  additional  inputs  relating  to  time  of  day,  weather 
conditions,  and  visibility.  Because  PlannedAssault  is  designed  to  complement  both  simu- 
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Please  select  the  objectives  for  your  mission  (maximum  1  per  side) 

Available  Objectives 

Clear.  Clear  this  position  of  hostile  forces  in  a  single  group 
attack. 

Selected  Objectives  BLOFOR 

t>  AMY.  Clear  FlankR.  Clear  this  position  of  hostile  forces  with  a 

2|FR  combined  main  attack  and  right  flank  attack. 

r 

r 

Clear  Two.  Clear  this  position  of  hostile  forces  in  a  two  pronged 
attack . 

Drag  an  objective  icon  to  one  of  the  above  positions  to  add  or  replace 
an  objective. 

Clear  FlankR.  Clear  this  position  of  hostile  forces  with  a 
combined  raain  attack  and  right  flank  attack. 

Selected  Objectives  OFFOR 

£ 

Clear  FlankL.  Clear  this  position  of  hostile  forces  with  a 
combined  main  attack  and  left  flank  attack. 

^  AARDVARK.  Hold.  Hold  this  position  at  all  cost. 

Clear  Flank.  Clear  this  position  of  hostile  forces  with  a 
combined  main  attack  and  flank  attack. 

Drag  an  objective  icon  to  one  of  the  above  positions  to  add  or  replace 
an  objective. 

r 

r 

Clear  Three.  Clear  this  position  of  hostile  forces  with  a  three 
pronged  attack. 

Hold.  Hold  this  position  at  all  cost. 

►  Tip:  Three  Pronged  Attacks 

The  battlefield  typically  contains  too  many  obstacles  to  allow  eight 
to  ten  large  units  to  maneuver  as  a  single  formation.  So  when 
attacking  with  many  large  units,  pick  a  ’Clear  2*  or  even  'Clear  3* 
objective  to  maneuver  with  a  two  respectively  three  pronged  attack. 

Figure  3.10:  PlannedAssault  Mission  Selection,  from  [32] 

lations  and  games,  the  scenario  designer  also  selects  to  play  the  role  of  either  a  participant 
or  an  observer.  Once  all  inputs  have  been  completed,  the  program  begins  the  process  of 
Hierarchical  Plan-Space  Planning. 

PlannedAssault’s  finished  product  is  a  mission  file  which  the  user  can  download  and  run 
in  the  appropriate  version  of  Bohemia  Interactive  software.  The  program  is  assessed  to 
produce  generally  realistic  schemes  of  maneuver  for  both  attacking  and  defending  forces. 
An  example  of  one  such  scenario  is  depicted  in  Figure  3.11  One  notable  aspect  of  the 
program  is  the  utilization  of  military  tactical  control  measures  (TCMs),  including  attack 
positions  and  phase  lines.  PlannedAssault  also  attempts  to  task  organize  a  force  in  a  way 
that  takes  advantage  of  its  subordinate  units’  capabilities.  Examples  of  this  include  utilizing 
indirect  fire  assets  to  cover  the  movement  of  an  assault  force,  and  placing  a  machine  gun 
unit  in  a  position  to  provide  suppressive  fires. 

3.2.4  PlannedAssault  Conclusion 

The  PlannedAssault  program  represents  a  revolutionary  step  in  the  process  of  creating  com¬ 
plex  military  battle  plans.  Several  aspects  of  the  program  have  the  potential  to  affect  the 
way  in  which  military  simulations  are  created.  The  first  feature  of  interest  is  the  graphical 
user  interface  and  the  unit  templates  which  allow  a  user  to  quickly  create  a  force.  The 
second  important  aspect  of  the  program  is  its  representation  of  tactical  military  tasks.  Fi¬ 
nally,  the  hierarchical  plan-space  planning  algorithm  is  a  potentially  revolutionary  way  of 
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Figure  3.11:  PlannedAssault  Example  Scheme  of  Maneuver 

utilizing  artificial  intelligence  to  derive  complex  plans.  Each  of  these  features  represents 
techniques  that  could  prove  extremely  valuable  to  military  simulations. 

3.3  Command  Ops 

Many  of  the  previously  mentioned  efforts  to  refine  AI  capabilities  involve  FPS  applications. 
While  these  games  have  made  important  strides  in  the  ability  to  create  dynamic  behavior, 
FPS  developers  are  not  the  only  group  interested  in  AI.  RTS  games  involve  a  large  mixture 
of  automated,  semi-automated,  and  player-controlled  agents  which  interact  with  each  other 
on  battlefields.  One  of  the  major  differences  between  the  two  is  that  FPS  applications  utilize 
entities  representing  individuals,  while  many  RTS  applications  utilize  entities  that  represent 
collections  of  individuals.  This  aspect  can  be  observed  in  the  RTS  screen  shot  depicted 
in  Figure  3.12.  Unlike  their  FPS  counterparts,  the  attractiveness  of  RTS  applications  is 
generally  not  built  upon  advanced  graphics  and  immersive  game  play.  RTS  games  depend 
more  heavily  upon  AI  techniques  than  many  other  genres.  Ensuring  that  friendly  and  enemy 
forces  behave  in  a  tactically  realistic  manner  is  an  important  requirement  for  producing  a 
game  that  is  enjoyable  for  players  and  commercially  successful. 

One  of  the  companies  that  has  made  notable  strides  in  this  field  is  Panther  Games,  creator 
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Figure  3.12:  Command  Ops  Screenshot,  from  [33] 

of  the  Command  Ops  (formerly  Airborne  Assault)  series  of  RTS  games.  Formed  in  1986, 
Panther  Games  is  an  Australian  company  that  has  produced  numerous  board  games  and 
RTS  computer  games.  True  to  the  motto  of  “When  Realism  Counts,”  Panther  Games  con¬ 
centrates  its  efforts  on  advancing  AI  wargame  techniques.  Focus  areas  for  AI  development 
include  the  following  aspects  [34]: 

•  enable  AI  to  manage  subordinates 

•  enable  macro-management 

•  support  a  military  command  structure 

•  model  realistic  decision  making 

•  represent  orders  delay  (simulate  surprise  and  the  Boyd  Cycle) 

Panther  Games’  success  has  not  only  enabled  them  to  create  a  series  of  RTS  games  each 
more  realistic  than  the  last,  but  has  also  brought  them  to  the  attention  of  several  profes¬ 
sional  military  organizations.  In  2010,  Panther  games  was  “awarded  a  contract  to  conduct 
a  scoping  study  for  the  Australian  Defence  Simulation  Office  (ADSO)  to  determine  the 
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defence  requirements  for  a  course  of  action  (COA)  analyser  simulation  tool  and  to  plan 
and  cost  the  development  of  the  Command  Ops  operational  warfare  simulation  to  meet  the 
Defence  requirements”  [35].  Since  then,  their  success  at  creating  wargame  AI  has  brought 
them  to  the  attention  of  many  other  organizations  including  the  U.S.  military. 

To  understand  the  reason  for  this  attention,  this  paper  will  discuss  some  of  the  AI  aspects 
found  in  two  applications  from  Panther  Games’  Command  Ops  series.  Conquest  of  the 
Aegean  (COTA)  is  an  RTS  game  released  in  2006  and  set  during  the  World  War  II  (WWII) 
Greek  Campaign.  Battles  from  the  Bulge  (BFTB)  was  released  in  2010  and  “covers  the 
climactic  WWII  struggle  in  the  Ardennes  region  of  Belgium  when  Hitler  launches  his  last 
offensive  just  before  Christmas  1944”  [35].  Built  upon  the  COTA  foundation,  BFTB  in¬ 
corporates  several  improvements,  most  notably  in  the  areas  of  unit  tasking  and  force  orga¬ 
nization.  Command  Ops  entities  generally  represent  military  units  that  range  from  platoon 
to  division  size,  and  have  been  cited  for  displaying  some  of  the  most  advanced  military  AI 
on  the  market.  Examples  of  these  units  and  the  orders  they  can  be  given  are  shown  in  Fig¬ 
ure  3.13  and  Figure  3.14.  Highly  acclaimed  by  the  gaming  industry,  COTA  was  the  recipi¬ 
ent  of  numerous  awards  including  the  Wargamer’s  Best  Wargame  (Gold),  CyberStratege’s 
Laurier  D’Or  (Game  of  the  Year)  and  War-Historical’s  Game  of  the  Year  (Gold)  [35].  Much 
of  this  success  can  be  attributed  to  the  creation  of  entities  that  are  “aware  of  their  situation, 
able  to  make  decisions,  able  to  act  within  a  command  structure  (receive  and  send  orders), 
and  able  to  act  independently”  [34]. 

3.3.1  Situational  Awareness 

One  of  the  first  requirements  for  the  creation  of  smart  entities  is  situational  awareness  of 
an  entity’s  surroundings.  While  there  are  many  things  to  be  aware  of,  they  can  generally  be 
categorized  as  friendly,  enemy,  or  spatial  (also  referred  to  as  terrain).  Knowledge  of  one’s 
own  forces  is  an  important  prerequisite  for  deciding  upon  a  course  of  action.  Some  of  the 
friendly  force  attributes  that  Command  Ops  considers  include  friendly  force  numbers,  ca¬ 
pabilities,  tasks,  and  plans.  Important  considerations  can  also  include  force  limitations  and 
current  location.  Once  friendly  force  information  has  been  processed,  friendly  forces  must 
attempt  to  collect  the  same  information  about  their  enemies.  Friendly  forces  must  priori¬ 
tize  which  enemies  present  the  most  danger,  which  enemies  create  unique  challenges,  and 
ultimately  which  ones  must  be  dealt  with  first.  An  additional  real  life  factor  implemented 
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Figure  3.13:  Command  Ops  Unit  Hierarchy,  from  [33] 


in  Command  Ops  is  intelligence  reliability.  Battlefield  information  for  both  friendly  and 
enemy  forces  is  rarely  perfect;  the  reliability  of  such  information  must  be  considered  be¬ 
cause  it  could  have  a  significant  impact  on  operations.  Examples  of  information  exchanged 
between  units  is  shown  in  Figure  3.15.  The  final  piece  of  situational  awareness  concerns 
spatial  or  terrain  factors.  Entities  in  Command  Ops  focus  on  where  they  are,  where  they 
can  go,  and  where  they  cannot  go.  These  factors  play  an  important  role  in  determining  if 
an  entity  must  react,  reassess,  or  replan  [34]. 

According  to  Panther  Games’  President  Dave  O’Connor, 


The  number  one  thing  that  you  have  to  get  right  is  route  finding.  If  you  can’t 
get  good  route  finding,  [then]  forget  doing  AI;  it  is  not  your  career.  It  is  funda¬ 
mental.  Of  all  the  things  you  do,  it  determines  how  smart  [your  entities  are],  if 
you  are  developing  in  any  form  of  a  spatial  environment.  [34] 


While  being  able  to  develop  good  routes  is  extremely  important,  being  able  to  develop 
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Figure  3.14:  Example  Orders  and  Associated  Parameters,  from  [33] 

routes  quickly  is  of  equal  concern.  Because  route  planning  and  line  of  sight  (LOS)  cal¬ 
culations  represented  two  of  the  game’s  most  computationally  expensive  algorithms,  Pan¬ 
ther  Games  developers  spent  a  great  deal  of  time  optimizing  these  processes.  Combining 
these  terrain  related  capabilities  with  information  on  the  dispositions  of  friendly  and  enemy 
forces,  is  an  action  that  makes  situational  awareness  a  fundamental  building  block  for  the 
creation  of  smart  entities. 

3.3.2  Decision  Making 

Decision  making  is  the  next  aspect  of  building  smart  entities.  One  of  the  unique  decision 
making  aspects  of  Command  Ops  is  the  use  of  doctrine.  While  doctrine  can  be  defined  in  a 
number  of  ways,  Dave  O’Connor  describes  doctrine  as  a  way  of  “doing  the  decision  making 
process  that  implements  a  task  or  a  plan”  [34].  Command  Ops  doctrine  can  be  viewed  as 
a  set  of  templates  that  are  consulted  during  the  production  of  scenario-specific  plans  and 
tasks.  Because  units  employ  different  types  of  doctrine,  the  entities  within  Command  Ops 
can  display  a  wide  variety  of  behaviors  that  are  representative  of  their  real  life  historical 
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Figure  3.15:  Orders  Traffic  During  Gameplay,  from  [33] 


counterparts.  Command  Ops  categorizes  its  doctrine  in  two  different  ways.  Plan  doctrine 
covers  rules  utilized  during  the  formal  planning  process.  Plan  doctrine  is  utilized  when  a 
unit  creates  a  new  plan  or  is  forced  to  replan.  This  differs  from  tactical  doctrine  which 
describes  lower  level  behaviors,  and  controls  how  units  react  to  immediate  events.  Tactical 
doctrine  is  assessed  continuously  throughout  the  game  [33]. 

The  basis  for  decision  making  within  Command  Ops  is  the  Boyd  Cycle  created  by  former 
United  States  Air  Force  (USAF)  Colonel  John  Boyd.  The  Boyd  Cycle  is  embodied  by  the 
observe,  orient,  decide,  act  (OODA)  loop  which  describes  the  actions  combatants  perform 
while  engaged  with  enemy  forces.  To  account  for  the  interactions  of  simulated  entities, 
Panther  Games  made  some  adjustments  to  the  Boyd  Cycle,  however  the  process  maintains 
the  spirit  of  the  original  OODA  loop.  Within  Command  Ops,  entities  receive  (orders), 
plan,  send  (orders),  act,  react,  and  assess  [34].  Receiving  is  the  first  step  in  the  process 
because  tasks  or  guidance  received  from  a  higher  headquarters  have  a  significant  affect  on 
a  unit’s  ultimate  actions.  When  this  guidance  is  combined  with  a  unit’s  level  of  situational 
awareness,  that  unit  is  able  to  create  its  own  plan  of  action.  Each  plan  contains  series 
of  tasks  which  are  the  actions  that  an  entity  intends  to  accomplish.  When  it  comes  time 
to  act,  Command  Ops  unit  actions  are  not  only  based  on  “hard  factors”  such  as  weapon 
performance  and  unit  maneuverability,  but  also  include  “soft  factors”  that  embody  human 
attributes  such  as  aggressiveness,  decision  making  ability,  and  fatigue  [34].  These  first  four 
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parts  of  the  Command  Ops  reaction  cycle  cover  the  actions  taken  in  the  traditional  OODA 
loop,  are  included  in  Command  Ops’  formal  planning  processes,  and  depend  heavily  upon 
plan  doctrine. 

It  is  important  to  recognize  that  planning  is  not  finished  once  a  prioritized  list  of  tasks  has 
been  produced  and  is  ready  for  execution.  The  dynamic  nature  of  combat  environments 
requires  units  that  can  react  to  unexpected  circumstances,  recognize  when  their  current 
plan  is  no  longer  feasible,  and  create  a  new,  more  suitable  plan.  The  fifth  step  in  the 
Command  Ops  decision  cycle,  react,  functions  similarly  to  the  immediate  action  (IA)  drills 
conducted  by  actual  military  units.  This  step  makes  use  of  Command  Ops’  tactical  doctrine, 
is  conducted  automatically,  and  is  mostly  driven  by  the  local  context  rather  than  the  overall 
mission.  [33].  Another  important  capability  of  Command  Ops  entities  is  their  ability  to 
change  or  refuse  orders.  One  of  the  ways  this  is  accomplished  is  through  the  reassess  step. 
The  dynamic  nature  of  combat  operations  often  serves  to  invalidate  existing  plans.  When 
this  happens  in  Command  Ops,  the  reassess  step  triggers  a  replan  and  the  reactivation  of 
the  formal  planning  process  [33].  Examples  of  this  include  a  damaged  entity’s  refusal  to 
advance  upon  a  larger  force  in  the  face  of  overwhelming  enemy  fire.  The  ability  for  the 
Command  Ops  AI  to  recognize  such  dilemmas  and  take  appropriate  actions  is  an  impressive 
accomplishment. 

3.3.3  Task  Organization 

Our  approach  was  to  support  a  command  structure...  if  you  can’t  do  that,  then 

you  can’t  really  model  military  operations.  -  Dave  O’Connor  -  Panther  Games 

[33] 


One  aspect  of  decision  making  not  discussed  in  the  previous  section  was  the  act  of  sending 
orders.  As  hierarchical  organizations,  most  military  units  can  be  expected  to  possess  a 
number  of  subunits.  Even  in  games  such  as  Command  Ops  where  a  single  entity  can  be 
used  to  represent  a  large  military  organization  such  as  a  company  or  battalion,  the  overall 
number  of  subunits  in  a  scenario  can  grow  quickly.  Expecting  a  player  to  control  every 
entity  is  an  unreasonable  task.  Command  Ops  solves  this  problem  by  enabling  a  player  to 
task  a  single  command-level  unit,  and  then  use  AI  to  properly  task  the  command-level  unit’s 
subordinate  units.  This  is  an  important  capability  that  requires  the  player  “to  trust  that  an 


47 


AI  controlled  subordinate  will  do  a  reasonable  job  of  managing  itself  and  its  subordinates” 
[34].  Accomplishing  this  required  Command  Ops  designers  to  develop  a  series  of  modular 
tasks  which  can  be  combined  to  create  a  battle  plan.  According  to  Dave  O’Connor,  making 
entities  aware  that  they  are  part  of  a  command  structure  was  the  key  to  producing  scalable 
and  reusable  tasks.  Assigning  tasks  to  subordinate  units  is  an  important  capability,  however 
additional  capabilities  are  needed  for  the  creation  of  smart  organizations. 

The  ability  to  create  and  adjust  a  unit’s  task  organization  is  the  second  requirement  for 
creating  smart  organizations.  To  best  deal  with  the  inherent  chaos  of  combat  operations, 
military  units  are  constantly  adjusting  their  task  organization.  One  example  of  this  tech¬ 
nique  involves  reinforcing  a  unit  prior  to  an  operation.  If  a  unit  is  tasked  with  conducting 
a  difficult  attack,  they  will  often  be  reinforced  with  mortar  units  that  will  be  used  to  cover 
their  approach,  and  assault  units  which  are  used  to  destroy  enemy  bunkers.  Another  sit¬ 
uation  that  requires  an  updated  task  organization  is  when  a  unit  is  tasked  with  a  mission 
that  requires  a  number  of  separate  forces  which  are  able  to  conduct  independent  or  semi¬ 
independent  operations.  If  a  mission  clearly  calls  for  one  assault  force  and  two  support  by 
fire  forces,  then  a  unit  must  adjust  the  organization  of  its  subordinates  so  that  forces  will 
be  available  for  each  of  these  roles.  This  task  could  involve  combining  or  dividing  existing 
subordinate  units. 

Much  of  the  capability  to  accomplish  this  depends  on  the  three  methods  through  which 
Command  Ops  organizes  its  command  structures.  The  first  method,  called  an  organic  com¬ 
mand  structure,  describes  a  unit’s  normal  command  structure.  The  second  method  is  the 
player  command  structure.  This  method  is  utilized  when  a  Command  Ops  player  places 
one  unit  under  the  command  of  another  organization.  An  example  of  this  is  when  a  player 
places  an  artillery  battalion  from  one  division  under  the  command  of  a  different  division. 
The  final  method  is  called  the  current  structure;  this  refers  to  situations  where  the  Command 
Ops  AI  has  provided  further  refinements  to  a  player’s  command  structure  [34].  Building 
upon  the  previous  example,  a  current  command  structure  could  be  observed  if  the  Com¬ 
mand  Ops  AI  moves  the  artillery  battalion  from  its  player-assigned  boss  (the  division)  to 
one  of  the  division’s  subordinate  brigades.  Such  actions  usually  occur  during  the  orders 
process  when  a  player  selects  the  units  that  are  to  receive  a  specific  order.  Command  Ops’ 
abilities  to  allocate  resources  in  an  intelligent  manner  and  to  assign  appropriate  tasks  to 
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subordinate  units  are  important  AI  advancements. 


3.3.4  Formal  Plan  Development 

Situational  awareness,  decision  making,  and  smart  organizations  are  important  features 
which  Panther  Games  has  spent  a  great  deal  of  resources  developing.  Each  of  these  aspects 
is  an  important  building  block  for  one  of  the  most  intriguing  aspects  of  Command  Ops,  its 
ability  to  create  realistic  military  plans.  In  part,  this  is  made  possible  because  Command 
Ops  designers  took  an  object  oriented  approach  when  designing  their  AI.  They  anticipated 
that  such  an  approach  would  facilitate  the  creation  of  a  scalable  planning  system  which 
would  function  regardless  of  the  entity  hierarchy  system  in  use  [33]. 

This  was  accomplished  by  embedding  decision  making  AI  into  every  Command  Ops  entity 
so  that  each  unit  could  receive  orders,  create  a  plan,  and  issue  orders.  Unlike  other  games 
which  utilize  separate  strategic  AI  and  tactical  AI  constructs,  the  AI  in  Command  Ops  is 
scalable  and  will  function  regardless  of  what  military  echelon  an  entity  represents  [33]. 
These  capabilities  are  utilized  within  a  process  that  Panther  Games  developers  refer  to 
as  spiral  plan  development.  “Spiral  plan  development  is  a  recursive  methodology  which 
allows  [Command  Ops  entities]  to  develop  a  plan  within  a  plan  within  a  plan...  It  is  a  way 
of  decomposing  complex  tasks”  [34].  Common  orders  within  Command  Ops  include  the 
following  [33]: 

•  Move,  Probe,  Attack 

•  Defend,  Delay,  Withdraw 

•  Fire,  Bombard 

•  Secure/Deny  Crossing 

•  Reorganize 

•  Rest 

To  understand  this  process,  one  must  first  understand  the  hierarchical  manner  in  which 
Command  Ops  organizes  its  plans.  Each  entity  has  an  overall  operational  plan  which  con¬ 
sists  of  a  number  of  mission  plans.  Each  mission  plan  is  composed  of  a  series  of  tasks. 
Major  task  components  include  a  subject  or  force  group  (series  of  forces  arranged  in  a 
tree),  an  action  to  perform,  and  an  objective.  The  key  part  to  recognize  is  that  these  tasks 
are  scalable,  and  can  be  assigned  to  any  size  force.  This  results  in  a  system  which  dis- 
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plays  many  aspects  of  composable  behaviors,  a  concept  that  seeks  to  create  “an  easy  to 
use,  adaptive,  and  flexible  framework  for  simulating  group  behaviors”  [5]. 


3.3.5  Command  Ops  Summary 

These  aspects  are  combined  with  a  few  other  techniques  to  form  the  foundations  of  an 
extremely  powerful  AI  system.  The  ultimate  result  is  an  RTS  game  which  contains  highly 
refined  AI  capabilities  that  have  caught  the  interest  of  both  the  U.S.  and  the  Australian 
militaries.  Command  Ops  AI  is  also  of  interest  to  FPS  developers.  Though  it  was  developed 
many  years  before  his  own  program,  PlannedAssault  creator  William  van  der  Sterren  stated 
that  Command  Ops  continues  to  embody  one  of  the  best  known  examples  of  AI  planning 
[36].  The  ability  to  integrate  these  techniques  into  modern  military  simulations  would 
provide  numerous  advantages  in  both  scenario  creation  and  model  realism. 


3.4  Tesla  Tactics  Language  and  Behavior  Validation 

The  validation  of  models  and  behaviors  is  an  important  process  that  affects  numerous  com¬ 
munities  in  both  the  civilian  and  DOD  realms.  Many  models  have  mature  validation  pro¬ 
cesses  and  procedures  that  can  be  utilized  to  assure  stakeholders  of  a  model’s  quality.  Un¬ 
fortunately,  the  same  cannot  be  said  for  those  systems  which  depend  heavily  upon  human 
behavior.  The  validation  of  automated  human  behavior  is  a  vital,  yet  underdeveloped  field. 
Figure  3.16  illustrates  the  complexities  of  HBR  validation. 

As  M&S  techniques  have  progressed,  a  need  has  arisen  to  ensure  M&S  products  are  suit¬ 
able  for  their  intended  purpose.  The  suitability  of  simulations  impacts  numerous  areas 
including  business  finances,  heavy  equipment  operator  safety,  and  the  combat  effective¬ 
ness  of  military  forces.  Because  of  the  serious  nature  of  these  impacts,  both  businesses  and 
the  government  have  placed  an  emphasis  on  formalizing  the  approaches  utilized  to  certify 
M&S  systems  [38].  The  process  of  ensuring  simulations  are  correct  and  reliable  is  referred 
to  as  verification  &  validation  (V&V)  [38].  Traditionally,  verification  can  be  thought  of  as 
answering  if  “one  built  the  model  right”  while  validation  can  be  thought  of  as  answering 
if  “one  built  the  right  model.”  Verification  determines  if  a  model  complies  with  specifica¬ 
tions  detailed  in  a  model’s  requirements.  Validation  is  a  process  that  determines  if  a  model 
accomplishes  its  intended  use  [39]. 
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Figure  3.16:  Validation  Task  Information  Flow,  from  [37] 


Two  recommendations  for  improving  HBR  validation  involve  maintaining  close  ties  with 
subject  matter  experts  (SMEs)  throughout  a  product’s  development,  and  constructing  a 
simulation  in  a  way  that  enables  the  developers  to  understand  what  is  going  on  inside  the 
model.  AI  developer  Evan  Clark  describes  a  method  for  doing  this  within  DOD  simula¬ 
tions.  Through  the  use  of  a  military  tactics  language  known  as  Tesla,  he  describes  a  behav¬ 
ior  composition  approach  to  simulations  which  integrates  SMEs  and  can  produce  models 
that  are  easier  to  validate.  Behavior  composition  is  a  process  through  which  complex  be¬ 
haviors  are  constructed  from  primitive  behaviors,  and  other  complex  behaviors.  Though 
the  exact  definition  can  vary,  primitive  behaviors  refer  to  “functionality  implemented  in 
source  code  and  packaged  up  so  as  to  be  available  to  an  editor  application  or  scripting  en¬ 
gine”  [40,  p.  12].  Behavior  composition  systems  can  generally  be  classified  as  goal-based 
systems  in  which  goals  are  assigned  to  individual  agents  and  groups,  or  knowledge-based 
systems  which  utilize  some  type  of  FSM.  Knowledge  based  systems  are  also  known  as 
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rule-based  systems  or  embedded  expert  systems  [40]. 


According  to  Clark,  the  Tesla  tactical  language  was  created  “to  bridge  the  gap  between 
the  art  and  science  of  war  studied  by  domain  SMEs  on  the  one  hand,  and  the  logic  and 
algorithms  of  software  applications  on  the  other”  [40,  p.  10].  Tesla  is  classified  as  a 
knowledge-based  system.  It  is  partly  graphical  and  partly  textual,  and  makes  heavy  use 
of  abstract  tactical  templates.  An  example  of  these  tactical  templates  is  depicted  in  Fig¬ 
ure  3.17.  One  of  the  strengths  of  the  system  is  that  it  can  express  complicated  behaviors 
more  easily  than  with  standard  knowledge-based  FSM  systems.  Additionally,  because  of 
the  language’s  graphical  nature  and  its  strong  tie  to  U.S.  military  doctrine,  Tesla  enables 
SMEs  to  play  a  significant  role  in  the  software  and  scenario  development.  One  of  the  key 
ways  it  accomplishes  these  attributes  is  through  the  use  of  abstract  tactical  templates.  The 
templates  themselves  are  created  using  Tesla’s  graphical  interface,  and  are  largely  com¬ 
posed  of  primitive  tasks,  constraints,  and  control  measures  familiar  to  military  personnel. 
Because  their  abstract  nature  prevents  references  to  specific  locations,  times,  or  actors,  the 
templates  possess  scalable  and  reusable  attributes,  which  can  significantly  ease  scenario 
development. 

While  the  ability  for  SMEs  to  participate  in  the  development  process  is  of  great  benefit, 
additional  aspects  of  the  Tesla  language  stand  to  ease  the  HBR  validation  process.  The  first 
benefit  of  Tesla  is  that  it  can  augment  face  validation  efforts.  Clark  states  that  Tesla  helps 
structure  validation  efforts  by  shifting  the  majority  of  the  work  to  “the  creation  and  approval 
of  test  scenarios  and  later  on  the  approval  of  template  libraries”  [40,  p.  9].  Additionally, 
the  reusable  nature  of  the  templates  means  that  they  can  be  created  and  validated  separately 
from  larger  scenarios.  One  of  the  problems  with  face  validation  is  designating  testing  inputs 
that  adequately  cover  the  required  behavior  space  [40].  Tesla  templates  ease  this  problem 
by  aiding  developers  in  partitioning  behavior  space.  Tesla’s  granular  knowledge  base  is 
easier  to  work  with  than  complex  knowledge  bases  full  of  interrelationships  [40].  Finally, 
an  important  benefit  of  the  Tesla  language  is  that  it  facilitates  the  involvement  of  SMEs 
throughout  the  development  process. 

Unfortunately,  the  Tesla  system  still  requires  qualitative  validation  techniques,  and  is  there¬ 
fore  still  subject  to  problems  including  limited  reusability  and  SME  bias.  Despite  this,  it 
provides  advantages  that  could  greatly  ease  the  development  and  validation  of  simulations 
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Figure  3.17:  Tesla  Tactical  Template,  from  [40] 

involving  automated  human  behavior.  Clark  states  that  “the  Tesla  system  is  an  approach 
to  tactical  behavior  composition  that  gives  control  over  more  behavioral  elements  to  the 
behavior  developer  than  previous  behavior  composition  systems...  [and]  would  augment 
current  face  validation  efforts  by  removing  impediments  identified  as  significant  hurdles  in 
past  high  profile  DOD  simulation  efforts”  [40,  p.  11]. 
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CHAPTER  4: 

Military  Doctrine  for  Simulations 


Throughout  the  course  of  human  history,  societies  have  sought  to  advance  current  mili¬ 
tary  tactics  in  order  to  give  themselves  an  advantage  over  their  competitors.  The  USMC 
provides  a  unique  example  of  this  concept.  One  of  the  Marine  Corps’  unique  qualities  is 
that  it  incorporates,  into  one  organization,  many  conventional  capabilities  such  as  infantry 
and  fixed-wing  aviation,  which  are  normally  separated  by  service.  For  this  reason.  Marine 
Corps  doctrine  is  written  in  a  manner  so  that  it  is  applicable  across  a  wide  spectrum  of 
capabilities.  A  second  quality  comes  from  its  tie  to  the  United  States  Navy  (USN),  a  re¬ 
lationship  that  gives  the  Marine  Corps  an  advantage  in  maneuverability  at  the  operational 
level  of  war.  However  one  of  the  drawbacks  of  staging  operations  from  ships  is  a  limitation 
on  the  number  of  assets  a  unit  can  bring  to  a  fight.  To  succeed  in  a  world  where  combat 
assets  may  be  limited,  the  Marine  Corps  finds  unique  ways  of  employing  the  people  and 
equipment  that  a  unit  has  available.  The  concept  of  combined  arms  is  one  principle  that 
Marines  utilize  to  gain  an  advantage  over  their  adversaries.  MCDP  1-0  describes  combined 
arms  in  the  following  way: 


Combined  arms  presents  the  enemy  not  merely  with  a  problem,  but  with  a 
dilemma-a  no-win  situation.  The  commander  combines  supporting  arms,  or¬ 
ganic  fires,  and  maneuver  in  such  a  way  that  any  action  the  enemy  takes  to 
counteract  one  makes  him  more  vulnerable  to  another.  [41,  p.  96] 


The  harmonious  execution  of  this  concept  produces  an  overall  unit  capability  which  is 
greater  than  the  sum  of  each  unit  member’s  capabilities.  Military  simulations  must  strive 
to  emulate  these  effects  if  they  are  expected  to  produce  outputs  which  are  representative 
of  actual  combat.  Unfortunately,  this  is  an  extremely  difficult  task  for  which  there  is  no 
simple  solution.  Software  programmers,  AI  experts,  and  simulationists  have  made  impor¬ 
tant  strides  in  creating  better  representations  of  human  behavior  in  combat,  but  there  is  still 
much  room  for  improvement. 
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One  way  to  improve  upon  combat  simulations  is  through  the  application  of  techniques 
found  in  military  doctrine.  Such  military  documents  and  manuals  offer  potential  solutions 
to  the  problem  of  replicating  human  behavior  in  simulations.  This  chapter  provides  a  gen¬ 
eral  understanding  of  important  command  concepts  and  doctrinal  terminology  needed  to 
produce  realistic  combat  simulations.  The  chapter  concludes  by  providing  insights  into  the 
mission  planning  process  for  a  basic  ground  attack. 

4.1  Mission  Command  and  Doctrinal  Terminology 

Military  doctrine  represents  the  collection,  organization,  and  evolution  of  hundreds  of  years 
of  military  knowledge.  The  behaviors  described  are  crafted  so  that  they  remain  relevant  in 
even  the  most  extreme  combat  situations.  Analyzing  these  techniques  is  an  important  step 
for  producing  a  representative  combat  simulation.  The  unique  two-way  communication 
techniques  and  considerations  between  leaders  and  soldiers  on  a  battlefield  incorporates 
many  aspects  that  could  prove  advantageous  to  AI  systems  attempting  to  replicate  human 
behavior.  To  understand  the  reason  for  this,  one  must  first  understand  certain  attributes  of 
the  high  intensity  battlefield  for  which  these  military  techniques  were  designed. 

•  Conventional  military  forces  are  organized  in  a  hierarchical  manner  in  order  to  enable 
rapid  reorganization. 

•  At  all  levels,  battlefield  friction  degrades  the  two-way  communication  capabilities 
between  units  and  leaders;  this  often  results  in  incorrect  information. 

•  Rapidly  changing  situations  often  invalidate  missions  previously  assigned  to  a  unit; 
a  mechanism  must  exist  for  unit  leaders  to  modify  their  mission  in  a  way  that  is 
beneficial  to  their  higher  headquarters. 

•  Personnel  changes  due  to  battlefield  casualties  can  often  cause  military  members  to 
be  placed  in  positions  for  which  they  lack  experience. 

If  military  operations  are  to  be  successful  under  these  harsh  conditions,  the  communications 
and  orders  passed  between  leaders  and  subordinates  must  be  clear,  concise,  and  flexible. 
The  Marine  Corps  accomplishes  this  through  the  concept  of  mission  command.  MCDP  1-0 
states  that  “under  mission  command,  commanders  provide  subordinates  with  a  mission, 
their  commander’s  intent,  a  concept  of  operations,  and  resources  adequate  to  accomplish 
the  mission”  [41,  p.  7-5].  Two  elements  of  mission  command  are  particularly  important 
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to  decentralized  execution.  The  concept  of  operations  is  an  overview  of  the  actions  that 
a  unit  will  perform  during  a  specific  mission.  According  to  MCDP  1-0,  “commander’s 
intent  is  the  commander’s  personal  expression  of  the  purpose  of  the  operation.  It  must  be 
clear,  concise,  and  easily  understood  two  levels  down.  It  may  also  include  end  state  or 
conditions  that,  when  satisfied,  accomplish  the  purpose”  [41,  p.  3-15].  Both  the  concept 
of  operations  and  commander’s  intent  are  powerful  methods  for  conducting  decentralized 
operations  in  which  leaders  at  all  levels  can  be  trusted  to  exercise  judgment  and  initiative. 
When  battlefield  events  nullify  the  utility  of  a  unit’s  specific  mission,  the  best  way  for  a 
unit  to  remain  relevant  is  for  its  leader  to  select  a  new  mission  that  is  nested  within  his 
commander’s  concept  of  operations,  or  is  beneficial  to  the  process  of  accomplishing  the 
commander’s  intent. 

Within  simulations,  the  dynamic  behavior  of  agents  can  be  improved  through  mechanisms 
that  represent  a  concept  of  operations  and  a  commander’s  intent.  However,  this  is  only  part 
of  the  solution.  Accomplishing  these  tasks  requires  standardized  terminology  that  can  be 
used  for  clear  and  concise  communication.  The  Marine  Corps  has  devoted  much  attention 
to  establishing  such  a  lexicon.  Clearly  defined  terminology  describes  operational  aspects 
that  range  from  the  type  of  operation  to  be  conducted,  to  the  general  type  of  behavior  that 
a  unit  will  execute,  to  the  specific  mission  that  subordinate  units  are  tasked  with  accom¬ 
plishing.  Understanding  this  terminology  is  a  vital  requirement  for  accurately  representing 
military  behavior  in  a  simulation. 


4.1.1  Classification  of  Marine  Corps  Operations 

Within  computer  programs,  parameters  play  an  important  role  in  the  actions  exhibited  by 
the  program.  The  terms  that  the  Marine  Corps  uses  to  define  its  actions  function  in  much 
the  same  way.  At  the  highest  level,  a  commander  must  select  a  major  operation  for  his  unit 
to  conduct.  The  most  fundamental  of  these  decisions  is  represented  by  a  choice  between 
offensive  and  defensive  operations.  This  is  a  complicated  decision  which  depends  on  nu¬ 
merous  factors  such  as  the  orders  a  unit  has  received  from  its  headquarters,  a  unit’s  current 
state,  and  the  unit’s  perception  of  its  enemy’s  state.  Because  a  unit’s  subsequent  actions  are 
completely  dependent  upon  this  choice,  AI  systems  in  simulations  must  be  able  to  make 
decisions  that  are  representative  of  those  of  military  commanders. 
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It  should  be  also  recognized  that  additional  types  of  major  operations  exist.  Areas  for  con¬ 
sideration  include  reconnaissance,  security,  counterinsurgency,  and  sustainment  operations. 
Amphibious  operations  have  their  own  subset  of  mission  types  including  raids,  assaults, 
withdrawals,  demonstrations,  and  support  to  other  operations  [41,  pp.  2-23  -  2-24].  The 
choice  among  each  of  these  operation  types  will  have  a  major  affect  on  the  unit’s  eventual 
actions.  Because  the  choice  between  offense  and  defense  represents  one  of  the  most  fun¬ 
damental  decisions  that  a  commander  must  make,  this  serves  as  a  logical  area  to  start.  The 
main  thrust  of  this  thesis  will  be  to  effectively  define  portions  of  offensive  operations  that 
are  applicable  to  military  simulations. 

4.2  Offensive  Operations  Overview 

MCDP  1-0  states  that  "offensive  operations  seek  to  gain,  maintain,  and  exploit  the  initiative, 
causing  the  enemy  to  react"  [41,  p.  6-4].  As  shown  in  Figure  4.1,  offensive  operations  are 
generally  divided  into  four  major  categories:  movement  to  contact,  attack,  exploitation, 
and  pursuit.  Each  of  these  operation  types  is  best  suited  to  different  situations.  They  are 
of  interest  to  military  simulation  designers  because  the  type  of  offensive  operation  a  unit 
conducts  will  have  a  major  impact  on  the  type  of  tactics  utilized,  the  allocation  of  external 
resources  such  as  fire  support,  and  the  unit’s  behavior  when  it  makes  contact  with  enemy 
forces.  Joint  Publication  1-02  and  MCDP  1-0  provide  the  following  descriptions  of  these 
operations. 

Movement  to  Contact:  “a  form  of  the  offense  designed  to  develop  the  situation  and  to 
establish  or  regain  contact”  [42,  p.  245].  The  purpose  of  this  offensive  operation  is  to 
further  develop  a  commander’s  knowledge  of  enemy  forces.  It  is  normally  conducted 
at  the  opening  stages  of  a  campaign.  It  requires  formations  specialized  for  scouting, 


Figure  4.1:  Four  Types  of  Offensive  Operations,  from  [41] 
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speed,  and  flexibility.  Figure  4.2  illustrates  how  a  unit  generally  task  organizes  its 
subunits  for  movement  to  contact  operations. 

Attack:  “an  offensive  operation  of  coordinated  movement  and  maneuver  supported  by  fire 
to  defeat,  destroy,  or  capture  the  enemy  or  seize/secure  key  terrain”  [41,  p.  9-5]. 
Exploitation:  an  offensive  operation  that  “disorganizes  the  enemy  in  depth  usually  fol¬ 
lowing  a  successful  attack.  The  exploitation  extends  the  initial  success  of  the  attack 
by  preventing  the  enemy  from  disengaging,  withdrawing,  and  re-establishing  an  ef¬ 
fective  defense"  [41,  p.  9-7].  Because  the  reserve  force  is  typically  tasked  with 
conducting  an  exploitation,  the  unit  commander  must  make  the  decision  to  execute 
this  offensive  operation  by  carefully  weighing  risks  and  rewards. 

Pursuit:  “an  offensive  operation  designed  to  catch  or  cut  off  a  hostile  force  attempting 
to  escape”  [41,  p.  9-8].  This  type  of  attack  requires  mobile  forces  that  can  quickly 
attack  an  enemy  which  is  also  moving. 

These  operations  are  defined  so  that  they  occur  in  a  logical  flow.  However,  it  should  be 
noted  that  they  will  not  always  be  performed  sequentially.  “For  example,  a  movement  to 
contact  may  be  so  successful  that  it  immediately  leads  to  exploitation  or  an  attack  may 
lead  directly  to  pursuit”  [41,  p.  9-4].  Additionally,  it  should  be  recognized  that  within  the 
bounds  of  a  single  operation,  the  same  unit  will  rarely  perform  all  four  types  of  offensive 
actions. 

4.2.1  Types  of  Attacks 

The  attack  offensive  operation  is  subdivided  into  several  categories.  These  include  hasty, 
deliberate,  spoiling,  counterattack,  feint,  demonstration,  reconnaissance  in  force,  and  raid. 


Figure  4.2:  Movement  to  Contact  Task  Organization,  from  [41] 
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They  are  significant  to  simulations  because  the  type  of  attack  selected  plays  a  major  role 
in  determining  a  unit’s  behavior.  The  choice  between  hasty  and  deliberate  attacks  affects 
the  amount  of  time  that  a  unit  spends  preparing  for  an  attack.  A  spoiling  attack  is  designed 
to  ruin  an  enemy’s  attempts  to  form  for  its  own  attack.  Feints,  demonstrations,  and  recon¬ 
naissance  in  force  operations  affect  the  criteria  in  which  a  unit  will  break  contact  when  it  is 
engaged  with  an  enemy  force.  A  raid  signals  that  a  unit  must  conduct  a  planned  withdrawal 
upon  completion  of  its  primary  mission.  Finally,  a  counterattack  is  conducted  by  a  unit  that 
is  normally  participating  in  a  larger  defensive  operation  [41,  pp.  9-5  -  9-6]. 

4.2.2  Forms  of  Maneuver 

Forms  of  maneuver  illustrate  the  manner  in  which  an  offensive  force  seeks  to  interact  with 
its  enemy.  If  a  unit  is  given  the  mission  of  attacking  an  enemy,  that  unit’s  form  of  maneuver 
plays  a  major  role  in  the  offensive  unit’s  path  selection.  It  also  affects  the  portion  of  the 
enemy  force  that  the  offensive  force  seeks  to  attack.  The  six  forms  of  maneuver  are  frontal 
attack,  flanking  attack,  envelopment  (single  or  double),  turning  movement,  infiltration,  and 
penetration.  The  frontal  attack,  flanking  attack,  and  penetration  are  of  interest  to  this  work 
and  are  depicted  in  Figure  4.3. 

A  frontal  attack  seeks  to  attack  the  main  enemy  force,  and  occurs  from  the  direction  that 
an  enemy  is  facing.  It  is  utilized  when  an  offensive  force  possesses  overwhelming  com¬ 
bat  power,  or  when  a  unit’s  direction  of  attack  is  fixed.  An  example  of  this  occurs  when 
offensive  operations  call  for  several  attacking  units  to  be  placed  next  to  each  other.  To 
minimize  the  possibility  of  fratricide,  the  direction  of  each  attacking  unit  must  correspond 
to  its  higher  headquarters’  direction  of  attack. 

A  flanking  attack  seeks  to  attack  a  vulnerable  portion  of  the  main  enemy  force.  The  primary 
example  of  this  involves  finding  a  direction  of  attack  that  avoids  the  area  that  is  covered  by 
the  majority  of  enemy  defenders.  Accomplishing  this  requires  pathfinding  capabilities,  and 
knowledge  of  an  enemy’s  orientation. 

A  penetration  disrupts  an  enemy  defensive  position  by  concentrating  an  attacking  force’s 
combat  units,  and  attacking  through  a  narrow  portion  of  the  enemy’s  position.  This  opera¬ 
tion  is  undertaken  to  disrupt  an  enemy  defensive  position  or  to  access  a  specific  capability 
in  the  enemy’s  rear  area.  Three  general  stages  of  penetration  include  rupturing  the  enemy 
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position,  widening  the  gap  so  that  follow-on  forces  can  move  through  it,  and  seizing  an 
objective  in  the  enemy’s  rear  area  [41,  p.  9-16]. 

The  three  additional  forms  of  maneuver  -  envelopment,  turning  movement,  and  infiltration 
-  play  important  roles  in  military  operations,  but  are  beyond  the  scope  of  this  work.  En¬ 
velopment  involves  maneuvering  around  or  over  an  enemy’s  primary  defense  in  order  to 
secure  an  objective  in  the  enemy’s  rear  area.  A  turning  movement  has  a  goal  similar  to  an 
envelopment,  however  the  distance  between  the  enemy’s  defensive  front  and  the  offensive 
force’s  objective  is  much  greater.  An  infiltration  involves  breaking  a  unit  down  into  small 
elements,  having  them  move  through  gaps  in  an  enemy  defense,  and  then  reassembling  in 
order  to  accomplish  a  separate  mission. 


Figure  4.3:  Frontal  Attack,  Flanking  Attack,  and  Penetration  Examples,  from  [41] 


4.2.3  Tactical  Tasks 

The  final  high  level  consideration  for  planning  a  military  operation  involves  the  assign¬ 
ment  of  specific  tasks  to  each  unit.  As  stated  in  MCDP  1-0,  “tactical  tasks  have  precise 
definitions  that  describe  what  is  to  be  accomplished”  [41,  p.  3-26].  Understanding  the 
definitions  of  each  task  is  important  for  military  members,  because  it  allows  missions  to  be 
communicated  more  easily. 

Tactical  tasks  can  be  classified  as  specified,  implied,  or  essential.  A  specified  tactical  task 
is  one  which  a  superior  gives  to  a  subordinate.  An  implied  tactical  task  is  one  which  a  sub¬ 
ordinate  has  not  been  told  to  do,  however  he  knows  it  must  be  done  in  order  to  accomplish 
his  primary  task.  An  essential  task  is  one  which  a  commander  identifies  as  being  vital  for 
the  overall  mission’s  accomplishment. 

It  is  important  to  recognize  that  tactical  tasks  can  have  different  areas  of  focus.  They  can  be 
enemy-oriented,  friendly  force-oriented,  terrain-oriented,  or  environmentally-oriented  [41, 
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pp.  C-l  -  C-6].  An  enemy-oriented  task  means  that  that  the  location  of  the  tactical  action 
is  dependent  upon  the  location  and  disposition  of  an  identified  enemy  force.  Examples  of 
this  include  block,  destroy,  and  support  by  fire.  Similarly,  a  friendly  force-oriented  task 
is  dependent  upon  the  location  and  disposition  of  an  identified  friendly  unit.  Examples 
include  follow  and  protect.  Terrain-oriented  tasks  are  the  final  type  of  task  applicable 
to  this  thesis.  In  this  situation,  a  unique  terrain  feature  is  the  driving  force  for  a  unit’s 
mission.  These  are  potentially  the  easiest  tasks  to  implement  in  simulations  because  the 
location  of  the  task’s  goal  is  generally  fixed.  Example  tasks  include  clear,  retain,  and  seize. 
Reconnoiter  can  be  a  terrain-oriented  or  an  enemy-oriented  task. 

The  correct  implementation  of  tactical  tasks  within  military  simulations  would  have  many 
positive  effects,  including  making  a  simulation  easier  to  construct  and  easing  communi¬ 
cation  difficulties  between  scenario  developers  and  military  officers.  For  a  complete  un¬ 
derstanding  of  USMC  tactical  tasks,  simulation  developers  should  reference  MCDP  1-0 
“Operations.”  A  basic  understanding  of  all  of  these  concepts  is  vital  to  making  simulations 
more  representative  of  actual  military  operations. 


4.3  Attack  Overview 

Planning  for  military  operations  is  a  complicated  task  comprised  of  many  steps.  One  gen¬ 
eralization  of  the  military  planning  process  divides  it  into  two  main  parts:  high-level  con¬ 
ceptual  planning  and  low-level  detailed  planning.  Both  steps  are  required  to  produce  an 
effective  plan.  Important  decisions  made  during  high-level  planning  include  classifying 
the  type  of  operation  to  be  conducted,  deciding  upon  a  general  form  of  maneuver,  and  de¬ 
veloping  a  mission  statement  which  makes  use  of  one  or  more  tactical  tasks.  When  these 
steps  have  been  accomplished,  a  plan  can  be  produced  that  details  exactly  how  a  unit  in¬ 
tends  to  accomplish  its  mission. 

Detailed  operational  planning  requires  numerous  decisions  that  involve  assigning  specific 
tasks  to  units,  prioritizing  the  operation’s  various  efforts,  and  establishing  movement  con¬ 
trol  measures.  This  section  discusses  several  of  the  key  decision  points  that  a  commander 
must  make  when  planning  the  actions  of  a  military  unit.  The  first  concept  discussed  in¬ 
volves  identifying  the  most  decisive  part  of  an  operation. 
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4.3.1  Main  and  Supporting  Efforts 

A  key  lesson  taught  to  Marine  Lieutenants  learning  the  art  of  defensive  tactics  is  that  if 
they  attempt  to  defend  everywhere,  then  they  will  effectively  defend  nowhere.  This  learn¬ 
ing  point  is  instrumental  in  teaching  the  concept  of  a  main  effort.  When  planning  an  op¬ 
eration,  Marine  commanders  identify  the  most  critical  or  decisive  aspect  of  the  operation. 
The  subordinate  unit  charged  with  achieving  this  task  is  designated  as  the  unit’s  main  ef¬ 
fort.  According  to  MCDP  1,  “the  main  effort  receives  priority  for  support  of  any  kind. 
It  becomes  clear  to  all  other  units  in  the  command  that  they  must  support  that  unit  in  the 
accomplishment  of  its  mission”  [43,  pp.  90-91].  Other  subordinate  units  are  designated  as 
supporting  effort  1,  supporting  effort  2,  and  so  forth.  The  amount  of  external  support  that  a 
subordinate  unit  receives  is  highly  dependent  upon  its  priority. 

Within  military  operations,  this  is  a  powerful  tool  that  increases  unity  of  effort  between  sub¬ 
ordinate  units,  and  focuses  combat  power  on  the  part  of  the  operation  that  the  commander 
views  as  his  bid  for  success.  This  concept  also  increases  a  commander’s  ability  to  adjust  the 
actions  of  subordinate  units  in  the  middle  of  combat  operations.  Should  a  unit  encounter 
an  unexpected  situation  or  an  unanticipated  opportunity,  a  commander  can  quickly  refo¬ 
cus  his  subordinate  units  by  designated  a  new  main  effort.  Employing  this  concept  within 
simulations  has  the  potential  to  greatly  increase  the  an  agent’s  ability  to  represent  realistic 
military  behaviors. 

4.3.2  Supporting  Relationship  Example 

While  the  concept  of  the  main  effort  is  important  to  military  operations,  it  should  be  recog¬ 
nized  that  this  does  not  prevent  other  subordinate  units  from  receiving  support.  The  military 
accomplishes  this  by  establishing  several  command  and  support  relationships  which  are  de¬ 
fined  in  MCDP  1-0.  For  the  purpose  of  the  following  example,  an  infantry  company  will 
serve  as  the  supported  unit.  Enabling  units  will  include  a  mortar  section,  a  machine  gun 
squad,  and  an  engineer  team. 

general  support  (GS):  “That  support  which  is  given  to  the  supported  force  as  a  whole  and 
not  to  any  particular  subdivision  thereof”  [41,  Glossary-15].  If  the  mortar  section  is 
placed  in  GS  of  the  infantry  company,  then  each  of  its  infantry  platoons  can  expect  to 
receive  fire  support.  When  determining  exactly  how  fire  support  will  be  apportioned, 
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a  commander  will  normally  publish  a  “priority  of  fires”  list  which  determines  what 
unit  receives  support  if  multiple  fires  requests  are  received  at  the  same  time, 
direct  support  (DS):  “A  mission  requiring  a  force  to  support  another  specific  force  and 
authorizing  it  to  answer  directly  to  the  supported  force’s  request  for  assistance”  [41, 
Glossary- 13].  A  machine  gun  squad  in  DS  of  a  platoon  gives  all  its  support  to  the 
platoon.  The  machine  gun  squad  is  tasked  by  that  unit’s  platoon  commander.  The 
platoon  commander  does  not  have  the  ability  to  reorganize  the  machine  gun  squad’s 
hierarchy.  This  relationship  is  utilized  when  a  commander  wants  to  reinforce  a  unit’s 
capabilities  for  a  specific  mission  or  for  a  temporary  amount  of  time.  If  required,  DS 
units  can  be  re-tasked  in  the  midst  of  combat  operations, 
attached:  This  relationship  is  utilized  when  an  enabling  force  is  placed  in  support  of  a 
specific  unit  for  an  extended  amount  of  time.  An  engineer  team  that  is  attached 
to  an  infantry  platoon  essentially  becomes  part  of  that  infantry  platoon.  Unlike  the 
previous  DS  example  with  the  machine  gun  squad,  the  platoon  commander  in  this 
situation  has  the  ability  to  change  the  task  organization  of  the  engineer  team. 

4.3.3  Tactical  Control  Measures 

One  of  the  final  detailed  steps  of  planning  involves  the  establishment  of  TCMs.  TCMs  are 
tools  that  a  commander  utilizes  to  coordinate  the  behavior  of  his  subordinate  units.  The 
definitions  for  the  meaning  of  each  TCM  is  standardized,  as  is  a  graphic  that  represents  the 
TCM  on  a  tactical  map.  A  complete  listing  of  Marine  Corps  and  Army  TCMs  can  be  found 
in  Marine  Corps  Reference  Publication  (MCRP)  5-12A,  “Operational  Terms  and  Graph¬ 
ics.”4  TCMs  are  defined  for  all  types  of  operations  in  which  the  Marine  Corps  participates; 
many  of  these  have  complex  meanings  that  are  beyond  the  scope  of  this  work.  The  follow¬ 
ing  case  study  of  a  basic  ground  attack  includes  additional  examples  of  TCMs  that  should 
be  implemented  in  a  simulation’s  mission  planner. 

4.4  Case  Study:  Conduct  of  an  Attack 

As  an  organization  whose  primary  purpose  is  to  be  on  the  offense,  the  conduct  of  a  basic 
infantry  attack  is  one  of  the  first  operations  that  Marines  are  taught  to  conduct.  Success¬ 
fully  accomplishing  an  attack  requires  the  coordinated  execution  of  numerous  basic  tasks. 

4For  U.S.  Army  forces,  this  publication  is  titled  FM  1-02  “Operational  Terms  and  Graphics.” 


64 


Marine  Corps  doctrine  eases  this  process  of  coordination  by  standardizing  the  actions  that 
a  unit  takes  when  conducting  an  attack.  Figure  4.4  illustrates  TCMs  that  depict  the  stages 
of  a  standard  attack.  The  intent  of  this  section  is  to  illustrate  the  military  techniques  and 
concepts  utilized  within  an  example  attack.  The  plan  will  be  developed  in  accordance  with 
the  following  high-level  attributes: 

Operation  Classification:  Offense 
Offensive  Operation  Type:  Attack 
Attack  Type:  Deliberate 
Form  of  Maneuver:  Frontal 
Mission:  Seize 

4.4.1  Preparation  Phase 

The  first  step  in  conducting  an  attack  involves  the  preparation  phase.  MCWP  3-11.2  states 
that  this  phase  is  “usually  accomplished  in  three  steps:  movement  to  the  assembly  area, 
final  preparations  in  the  assembly  area,  and  movement  to  the  line  of  departure”  [44,  p.  4- 
2],  The  first  step  requires  most  units  to  converge  on  a  designated  assembly  area.  Because 
the  assembly  area  is  generally  located  in  a  secure  portion  of  the  battlefield,  movement  is 
often  conducted  in  an  administrative  manner  in  order  to  maximize  speed.  Likely  forma¬ 
tions  include  a  route  column  or  a  tactical  column.  If  the  assembly  area  is  not  located  in 
a  secure  portion  of  the  battlespace,  subordinate  units  should  move  to  the  assembly  area  in 
an  appropriate  tactical  formation.5  The  appropriate  security  posture  is  dependent  upon  the 
situation.  The  chance  of  making  contact  with  an  enemy  force  is  generally  classified  as  con¬ 
tact  remote,  contact  possible,  contact  probable,  or  contact  imminent.  Units  typically  adopt 
a  tactical  formation  and  a  security  posture  that  is  appropriate  to  their  perceived  chance  of 
making  contact  with  an  enemy  force. 

The  assembly  area  is  generally  where  units  conduct  their  final  planning  and  preparations 
prior  to  conducting  an  attack.  Some  actions  in  the  assembly  area  are  not  applicable  to 
simulations,  however  other  aspects  should  be  considered  for  inclusion  in  an  automated 
mission  planner.  First,  there  will  be  some  type  of  security  in  an  assembly  area.  If  security 

5It  should  be  noted  that  in  this  context,  the  term  formation  refers  to  the  physical  disposition  of  the  members 
of  a  unit  both  when  the  unit  is  moving,  and  when  it  is  not  moving.  This  differs  from  the  way  that  the  term 
formation  is  used  in  COMBATXXI  where  it  is  usually  only  applicable  to  moving  units. 
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Figure  4.4:  Tactical  Control  Measures  for  a  Basic  Attack,  from  [44] 


is  not  being  provided  by  an  external  unit,  then  the  attacking  unit  itself  will  form  a  360 
degree  perimeter.  Adjustments  to  subordinate  unit  task  organization  will  be  made,  and 
units  will  begin  getting  into  the  proper  order  of  movement  dictated  in  the  attack  order. 

The  next  step  in  an  attack  is  to  begin  movement  from  the  assembly  area  to  the  line  of 
departure.  This  step  has  several  key  aspects  that  should  be  incorporated  into  simulations. 
The  first  item  of  interest  is  the  trigger  that  causes  a  unit  to  begin  its  movement.  This  trigger 
can  be  an  order  from  higher  headquarters,  a  signal  of  some  type,  a  specified  time,  or  a 
condition  that  describes  the  state  of  the  environment. 

When  a  unit  begins  movement,  they  must  be  in  the  proper  order  of  movement.  As  before, 
tactical  formations  will  still  depend  on  the  current  enemy  threat,  however  the  formation  is 
likely  to  employ  at  least  some  additional  security  mechanisms.  This  is  typically  the  first 
step  where  a  unit  employs  the  concept  of  a  base  unit.  This  is  an  important  mechanism  for 
controlling  the  movement  of  large  numbers  of  individuals,  and  is  employed  in  all  types  of 
military  operations. 


66 


Base  Unit 

According  to  MCWP  3-11.2,  the  base  unit  is  designated  by  the  commander  to  assist  in 
maintaining  direction,  position,  and  rate  of  march  [44,  p.  4-16].  Other  units  use  the  base 
unit  as  a  guide  to  adjust  their  own  movements.  It  is  important  to  note  that  the  base  unit  is 
not  necessarily  the  main  effort.  The  base  unit  can  also  change  throughout  the  course  of  an 
operation.  The  unit  selected  for  this  task  is  often  the  subordinate  unit  that  the  commander 
feels  can  best  navigate  the  force  to  its  destination.  In  this  case,  the  unit’s  destination  is  an 
attack  position. 

Attack  Position 

According  to  MCWP  3-1 1.2,  “the  attack  position  is  the  last  concealed  and  covered  position 
occupied  by  assault  echelons  before  crossing  the  line  of  departure.  It  is  the  location  where 
final  coordination,  last-minute  preparations,  and,  if  not  already  accomplished,  deployment 
into  initial  attack  formations  are  effected”  [44,  p.  4-20]. 

4.4.2  Movement  From  the  Line  of  Departure  to  the  Assault  Position 

The  next  portion  of  an  attack  is  the  conduct  phase.  By  doctrine,  it  begins  when  the  first 
troops  cross  a  phase  line  (PL)  known  as  the  line  of  departure  (LD). 

Phase  Line 

Joint  Publication  1-02  defines  a  PL  as  “a  line  utilized  for  control  and  coordination  of  mil¬ 
itary  operations,  usually  an  easily  identified  feature  in  the  operational  area.”  [42,  p.  282]. 
PLs  can  be  used  to  coordinate  actions  such  as  maneuver  or  fires.  If  a  PL  is  used  to  coor¬ 
dinate  maneuver,  then  units  are  generally  not  allowed  to  cross  it  until  an  order  is  received 
or  certain  conditions  are  met.  If  a  PL  is  used  to  coordinate  fires,  then  fires  agencies  will  be 
instructed  to  commence,  shift,  or  cease  fires  when  a  unit  crosses  the  PL.  Operation  specific 
PLs  can  be  created  in  addition  to  the  ones  discussed  in  this  case  study.  PLs  are  usually 
named  after  colors. 

Line  of  Departure 

MCWP  3-1 1.2  states  that  “the  line  of  departure  is  a  line  established  to  coordinate  attacking 
units  when  beginning  the  attack”  [44,  p.  4-34].  This  is  a  PL  that  is  given  its  own  name 
because  it  is  incorporated  into  most  military  operations.  Units  are  not  allowed  to  cross  the 
line  of  departure  until  certain  conditions  are  met,  or  triggers  are  received. 
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When  a  unit  crosses  the  line  of  departure,  they  generally  adopt  a  higher  security  posture. 
The  most  common  threat  state  is  contact  probable,  however  certain  situations  could  be 
classified  as  contact  possible  or  contact  imminent.  The  base  unit  concept  continues  to 
serve  as  an  important  technique  for  coordinating  the  movements  of  individual  combatants. 
Depending  on  the  type  of  formation  adopted,  it  is  possible  for  a  commander  to  re-designate 
his  base  unit. 

At  this  point,  a  unit  is  maneuvering  to  its  assault  position.  While  this  simple  attack  example 
incorporates  only  basic  techniques  and  TCMs,  MCWP  3-11.2  describes  several  additional 
concepts  that  are  worth  noting. 

Release  Point:  clearly  defined  points  where  units  are  released  to  the  control  of  their  re¬ 
spective  leaders  [44,  p.  4-36].  If  an  attack  plan  calls  for  it,  this  is  typically  the  area 
where  maneuver  elements  break  away  from  base  of  fire  elements. 

Base  of  Fire  Element:  “the  base  of  fire  covers  the  maneuver  element’s  advance  toward 
the  enemy  position  by  engaging  all  known  or  suspected  targets.  Upon  opening  fire, 
the  base  of  fire  seeks  to  gain  fire  superiority  over  the  enemy”  [44,  p.  4-22]. 
Maneuver  Element:  “the  mission  of  the  maneuver  element  is  to  close  with  and  destroy 
or  capture  the  enemy.  It  advances  and  assaults  under  covering  fire  of  the  base  of 
fire  element.  The  maneuver  element  uses  available  cover  and  concealment  to  the 
maximum”  [44,  p.  4-22], 

Fire  and  Maneuver:  “the  process  whereby  elements  of  a  unit  establish  a  base  of  fire  to 
engage  the  enemy,  while  another  element  maneuvers  to  an  advantageous  position 
from  which  to  close  with  and  destroy  or  capture  the  enemy.  Supporting  fires  from 
weapons  not  organic  to  the  unit  may  be  provided”  [44,  p.  4-21]. 


Assault  Position 

The  focus  of  this  stage  is  on  maneuvering  the  entire  force  to  the  assault  position.  MCWP  3- 
11.2  states  that  “the  assault  position  is  located  as  close  as  the  assaulting  element  can  move 
by  fire  and  maneuver  without  sustaining  casualties  or  masking  covering  direct  or  indirect 
fires.  The  assault  position  should  be  easily  recognizable  on  the  ground  and  ideally  should 
offer  concealment  and  cover  to  the  attacking  force”  [44,  p.  4-25]. 
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Direction  of  Attack 

The  location  of  an  assault  position  depends  heavily  on  whether  or  not  a  unit  has  been 
granted  the  ability  to  choose  its  direction  of  attack.  If  a  unit  is  given  the  ability  to  choose 
their  own  direction  of  attack,  then  they  can  locate  their  assault  position  in  the  place  that 
most  supports  their  scheme  of  maneuver.  This  situation  generally  occurs  when  the  attacking 
unit  is  the  only  force  attacking  an  enemy  objective,  and  when  it  does  not  have  to  worry 
about  its  fires  affecting  adjacent  friendly  forces.  However,  if  a  unit’s  direction  of  attack 
has  been  specified,  then  its  options  are  more  limited.  This  situation  occurs  when  multiple 
units  are  attacking  the  same  objective,  or  when  a  maneuvering  element  seeks  to  close  on  an 
enemy  position,  but  not  get  in  the  way  of  suppression  provided  by  the  base  of  fire  element. 

4.4.3  Movement  From  the  Assault  Position  Through  the  Objective 

The  next  stage  involves  movement  from  the  assault  position  to  the  enemy  objective.  Be¬ 
cause  assault  positions  have  a  high  likelihood  of  being  covered  by  enemy  indirect  fire 
weapons,  a  unit  will  stay  in  the  assault  position  only  as  long  as  is  necessary  to  make  fi¬ 
nal  preparations.  For  a  simulation,  this  will  typically  mean  moving  a  unit  into  its  final 
assault  formation,  and  updating  the  environment  state  to  contact  imminent.  Though  there 
is  not  an  official  “line  of  departure-type”  PL  between  the  assault  position  and  the  objective, 
units  will  often  coordinate  their  actions  with  something  known  as  an  inter-visibility  (IV) 
line.  This  is  typically  a  terrain  feature  that  provides  the  last  amount  of  concealment  between 
an  attacking  force  and  an  enemy  defense.  The  attacking  force  will  attempt  to  simultane¬ 
ously  cross  the  IV  line  with  as  many  combatants  as  possible  in  order  to  have  the  maximum 
number  of  weapons  systems  available  for  firing  on  enemy  positions.  Because  of  the  hectic 
nature  of  this  stage,  success  is  heavily  dependent  on  the  execution  of  specific  battle  drills 
and  leadership  techniques  which  are  described  in  MCWP  3-11.2. 

Fire  and  Movement:  “Once  the  maneuver  element  meets  enemy  opposition  and  can  no 
longer  advance  under  the  cover  of  the  base  of  fire,  it  employs  fire  and  movement  to 
continue  its  forward  movement  to  a  position  from  which  it  can  assault  the  enemy 
position.  In  a  maneuvering  squad,  fire  and  movement  consists  of  individuals  or  fire 
teams  providing  covering  fire  while  other  individuals  or  fire  teams  advance  toward 
the  enemy  or  assault  the  enemy  position”  [44,  p.  4-21]. 

Fighter-Leader  Concept:  “In  the  attack,  fire  team  leaders  act  as  fighter- leaders,  control- 
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ling  their  fire  teams  primarily  by  example.  Fire  team  members  base  their  actions  on 
the  actions  of  their  fire  team  leader.  Throughout  the  attack,  fire  team  leaders  exer¬ 
cise  such  positive  control  as  is  necessary  to  ensure  that  their  fire  teams  function  as 
directed”  [44,  pp.  4-22  -  4-23]. 

Squad  Leader  Actions  in  the  Assault:  “The  squad  leader  locates  himself  where  he  can 
best  control  and  influence  the  action...  To  maintain  control  of  the  squad  under  heavy 
enemy  fire,  the  squad  leader  positions  himself  near  the  fire  team  leader  of  the  desig¬ 
nated  base  fire  team.  By  regulating  the  actions  of  the  base  fire  team  leader,  the  squad 
leader  retains  control  of  the  squad.  The  base  fire  team  leader  controls  the  actions  of 
his  fire  team;  the  other  fire  team  leaders  base  their  actions  on  those  of  the  base  fire 
team”  [44,  p.  4-23].  Alternate  locations  for  a  squad  leader  include  positions  that 
offer  better  abilities  to  observe  the  fight,  to  communicate  instructions,  or  to  control 
key  weapon  systems. 

Final  Coordination  Line  &  Limit  of  Advance 

As  the  assaulting  force  makes  its  final  advance  toward  the  enemy  position,  it  relies  upon 
the  suppressive  effects  of  friendly  fires  to  prevent  enemy  forces  from  returning  effective 
fire.  If  external  agencies  are  being  used  to  provide  suppressive  fires,  the  assault  unit  will 
pass  through  PLs  that  trigger  the  supporting  agencies  to  shift  or  cease  fire.  The  PL  at  which 
all  external  fires  cease  is  called  the  final  coordination  line  (FCL).  At  this  point,  the  assault 
force  depends  on  its  own  fires  to  suppress  enemy  positions.  When  the  assault  force  closes 
the  distance  to  the  enemy  position,  it  makes  use  of  grenades,  suppressive  fire,  and  close 
combat  to  eliminate  enemy  forces.  The  assault  ends  when  the  unit  reaches  the  limit  of 
advance  (LOA).  This  is  a  final  PL  that  is  established  beyond  the  objective.  At  this  point, 
the  unit  begins  the  consolidation  and  reorganization  phase. 

4.4.4  Consolidation  and  Reorganization 

Due  to  casualties,  low  ammunition,  and  general  disorganization,  an  assaulting  force  is  typi¬ 
cally  at  its  most  vulnerable  when  it  reaches  the  LOA.  For  this  reason,  this  is  the  time  period 
during  which  it  must  be  most  concerned  about  enemy  counterattack.  MCWP  3-11.2  states 
that  “consolidation  is  the  rapid  organization  of  a  hasty  defense  in  order  to  permit  the  at¬ 
tacking  unit  to  hold  the  objective  just  seized  in  the  event  of  an  enemy  counterattack”  [44,  p. 
4-30].  Goals  during  this  step  include  redistributing  ammunition  and  positioning  forces  so 
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that  all  sectors  of  fire  are  covered.  The  direction  that  a  unit  covers  is  generally  the  direc¬ 
tion  in  which  it  was  attacking,  however  this  could  change  depending  upon  unique  enemy 
situations  or  terrain  features.  If  a  unit  includes  members  with  automatic  weapons,  those 
individuals  are  usually  positioned  to  cover  the  enemy’s  most  likely  avenues  of  approach. 
During  consolidation,  the  emphasis  is  on  quickly  establishing  a  defensive  position  and  not 
reforming  units.  Units  which  have  become  fragmented  during  the  assault  will  not  reform 
until  the  order  to  reorganize  has  been  given. 

Reorganization  is  a  process  which  refines  many  of  the  hasty  defensive  measures  taken 
during  consolidation.  This  process  involves  tying  together  the  flanks  of  multiple  defensive 
positions,  replacing  leadership  and  automatic  riflemen  who  have  become  casualties,  and  re¬ 
forming  units  which  were  separated  during  the  assault.  The  positioning  of  special  weapons 
systems  such  as  machine  guns,  rocket  launchers,  and  mortars  may  also  be  adjusted  during 
this  final  step. 


4.5  Additional  Considerations  for  Implementing  Military 
Doctrine  in  Simulations 

This  chapter  discussed  high  level  issues  that  are  typically  considered  when  a  commander 
develops  an  offensive  operation,  and  presented  a  case  study  of  a  basic  ground  attack.  The 
following  section  details  additional  considerations  of  interest  to  military  planners  and  sim¬ 
ulation  developers.  These  techniques  are  conducted  by  units  at  all  echelons  of  command. 

4.5.1  Relative  Combat  Power  Analysis 

According  to  MCWP  5-1,  “relative  combat  power  analysis  (RCPA)  provides  planners  with 
an  understanding  of  friendly  and  adversary  strengths  and  weakness  relative  to  each  other. 
While  force  ratios  may  be  important,  the  numerical  comparison  of  personnel  and  major  end 
items  is  just  one  factor  to  balance  with  other  factors,  such  as  leadership,  morale,  equipment 
maintenance,  training  levels,  weather,  demographics,  and  cultural  environment”  [45,  p.  2- 
5].  While  commanders  planning  operations  utilize  this  tool  to  help  decide  upon  courses 
of  action,  it  can  also  be  used  in  the  midst  of  operations  to  determine  appropriate  tactical 
behaviors. 
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4.5.2  Suppress,  Assess,  Move,  Kill 

The  suppress,  assess,  move,  kill  (SAM-K)  principle  is  used  by  combat  forces  to  enable 
movement  in  the  face  of  enemy  opposition.  This  is  a  technique  which  should  be  of  interest 
to  military  simulations.  The  first  step  in  this  process  is  to  assign  subordinate  forces  the 
mission  of  suppressing  perceived  enemy  positions.  When  they  begin  this  action,  the  unit 
leader  will  assess  whether  or  not  the  enemy  is  adequately  suppressed.  If  not,  the  leader  will 
modify  his  orders  concerning  the  suppression  of  enemy  positions.  If  the  unit  leader  believes 
the  enemy  is  suppressed,  then  he  will  authorize  another  portion  of  his  unit  to  maneuver  to 
its  next  position.  This  process  is  repeated  until  some  or  all  of  the  unit  has  reached  a  position 
that  allows  the  destruction  of  the  enemy  force,  or  the  accomplishment  of  the  unit’s  assigned 
mission  [46,  p.  7-56]. 

Defining  effective  suppression  is  a  difficult  task  that  must  be  accomplished  in  order  for 
the  SAM-K  principle  to  work.  The  following  list  describes  the  techniques  that  Marine 
instructors  use  within  training  scenarios  to  define  effects  of  enemy  suppression  on  a  moving 
unit  [47,  p.  3]. 

No  Fire:  unit  can  move  freely 

Sporadic  Fire:  unit  is  receiving  pop-shots  from  enemy  forces,  but  can  continue  to  move 
Effective  Fire:  unit  can  continue  as  long  as  they  perform  good  fire  and  movement 
Heavy  Fire:  moving  unit  is  pinned  down  and  can  not  move  without  assistance 


4.5.3  Battlespace 

A  commander  will  often  divide  his  battlespace  into  different  categories.  Typical  classifica¬ 
tions  include  an  area  of  operations,  an  area  of  influence,  and  an  area  of  interest.  Classifica¬ 
tions  are  assigned  based  on  a  military  commander’s  ability  to  affect  an  area.  The  doctrinal 
definition  for  these  terms  is  found  in  JP!  (JP!)  1-02  “DOD  Dictionary  of  Military  and  As¬ 
sociated  Terms.”  A  major  purpose  of  these  classifications  is  to  shape  a  unit’s  intelligence 
collection  efforts.  Within  simulations,  a  battlespace  management  tool  would  be  useful  for 
scoping  the  amount  of  information  that  is  used  to  build  a  unit’s  situational  awareness. 
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4.5.4  Areas  for  Future  Consideration 

The  attack  case  study  in  this  chapter  presents  a  synopsis  of  a  basic  attack  as  one  is  described 
in  MCWP  3-11.2  Marine  Rifle  Squad.  An  attack  is  one  of  the  fundamental  behaviors  upon 
which  many  other  actions  are  built.  If  a  simulation  is  able  to  correctly  replicate  the  actions 
taken  during  an  attack,  then  other  behaviors  should  be  considered. 

Defensive  Operations:  Offensive  and  defensive  operations  are  closely  linked.  Successful 
units  must  be  able  to  transition  seamlessly  between  the  two. 

Complex  Offensive  Operations:  In  normal  operations,  units  rarely  conduct  attacks  by 
themselves.  Marines  seek  to  utilize  the  combined  arms  concept;  this  technique  calls 
for  the  integration  of  a  variety  of  units  and  weapons  systems. 

Specialized  Actions:  Units  and  subordinate  units  will  often  be  required  to  perform  spe¬ 
cialized  actions  in  response  to  specific  situations.  Such  tactical  operations  include 
passage  of  lines,  linkups,  reliefs  in  place,  obstacle  crossings,  and  breakouts  from 
encirclement  [41,  p.  6-4]. 
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CHAPTER  5: 

Challenges  Inherent  to  Scripted  Scenarios 


One  of  the  difficult  areas  of  human  behavior  representation  concerns  choosing  a  test  sce¬ 
nario  that  is  capable  of  demonstrating,  and  ultimately  validating,  the  simulated  human  be¬ 
havior.  Just  because  a  simulation  is  capable  of  creating  reasonable  human  behavior  in  one 
situation  does  not  mean  it  will  be  capable  of  doing  so  under  different  conditions.  A  poten¬ 
tial  solution  to  this  problem  can  be  found  by  studying  and  simulating  pre-existing  military 
training  scenarios. 

The  Marine  Corps  Air  Ground  Combat  Center  (MCAGCC)  in  29  Palms,  California,  is  the 
Marine  Corps’  premier  location  for  conducting  live  fire  combined  arms  training.  Within  the 
MCAGCC,  Range  400  (R400)  and  Range  401  (R401)  are  the  primary  venues  for  training 
Marines  to  conduct  a  company  (reinforced)  live  fire  attack.  R400  has  existed  for  many 
years,  while  R401  was  created  during  the  wars  in  Iraq  and  Afghanistan  in  order  to  allow 
more  forces  to  conduct  training.  Both  of  these  ranges  achieve  similar  training  objectives  in 
similar  terrain.  R400  has  been  selected  for  this  study  because  of  the  existence  of  additional 
literature  concerning  range  operations  and  more  mature  performance  evaluation  standards. 
Figure  5.1  and  Figure  5.2  depict  the  notional  enemy  defensive  position  that  Marines  are 
assigned  to  attack  at  R400.  It  should  be  noted  that  light  armored  vehicle  (LAV)  platoons 
are  also  able  to  conduct  offensive  actions  on  this  range. 

5.1  Range  400  Overview 

The  execution  of  R400  at  MCAGCC  is  a  capstone  event  for  USMC  infantry  units.  The 
first  reason  for  this  is  that  R400  involves  the  use  of  every  type  of  weapon  system  that  is 
organic  to  a  Marine  infantry  battalion.  Each  R400  run  involves  an  infantry  company  which 
has  been  reinforced  by  battalion  81mm  mortars,  heavy  machine  guns,  and  scout  snipers. 
Additionally,  Combat  Engineer  units  are  usually  placed  in  support  of  infantry  companies. 
The  second  reason  for  this  range’s  importance  concerns  its  associated  training  goals.  These 
goals  include  small  unit  tactical  actions  such  as  grenade  employment,  trench  clearing,  fire 
and  movement,  and  fire  and  maneuver.  Higher  level  command  and  control,  and  fire  support 
coordination  skills  are  also  practiced  at  R400.  Training  goals  for  all  of  the  company’s 
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Figure  5.1:  Notional  Enemy  Forces  on  R400,  from  [47] 


specialized  units  and  battalion  reinforcements  are  also  integrated  into  the  range.  The  final 
reason  for  the  range’s  importance  concerns  evaluation  procedures. 

R400  training  goals  are  directly  tied  to  performance  standards  described  in  the  USMC  T&R 
manual.  Evaluations  are  conducted  by  Marines  from  the  Tactical  Training  Exercise  Control 
Group  (TTECG).  These  Marines  accompany  each  unit  during  its  R400  run,  and  fulfill 
several  important  actions.  First,  they  provide  an  assessment  on  how  well  units  execute 
appropriate  battle  drills,  how  efficiently  they  communicate,  and  how  the  units’  leaders  make 
decisions.  Next,  the  evaluators  have  the  ability  to  adjust  the  type  of  simulated  enemy 
actions  that  the  training  unit  faces  during  its  range  run.  These  simulated  enemy  actions 
known  as  “paints”  typically  involve  describing  the  type  and  volume  of  enemy  fire  that 
a  friendly  unit  is  receiving.  The  paints  have  an  effect  on  the  available  actions  a  unit  can 
take.  They  force  unit  commanders  to  make  good  decisions  and  execute  tactical  actions  with 
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Figure  5.2:  Range  400  Company  Commander  Brief  Sheet,  from  [47] 


precision.  Finally,  the  evaluators  document  each  unit’s  R400  performance  so  that  higher 
level  commanders  can  assess  the  proficiency  of  one  of  the  most  fundamental  infantry  units, 
the  reinforced  infantry  company.  Because  of  the  range’s  comprehensive  training  goals  and 
because  of  the  serious  manner  in  which  Marine  Corps  leadership  views  the  execution  of 
this  range,  a  simulated  version  of  R400  is  the  perfect  venue  for  assessing  the  effectiveness 
of  a  military  simulation’s  ability  to  execute  automated  tactical  behaviors. 

An  example  R400  attack  is  depicted  in  Appendix  B.  This  example  attack  involves  a  rein¬ 
forced  infantry  company  conducting  an  attack  against  the  range’s  standard  array  of  enemy 
forces.  While  this  organization  is  typical  for  actual  Marine  units  conducting  exercises  at 
R400,  this  setup  is  not  required  for  simulated  versions  of  R400.  Within  COMBATXXI,  ad¬ 
justing  the  size  and  composition  of  friendly  and  enemy  forces  allows  simulation  designers 
to  test  many  aspects  of  automated  tactical  behavior  capabilities. 
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5.2  Training  Objectives  and  Performance  Evaluation 

Because  the  normal  size  of  unit  conducting  training  at  R400  is  an  infantry  company  rein¬ 
forced  by  battalion  assets,  numerous  tactical  actions  are  available  for  evaluation.  Figure  5.3 
and  Figure  5.4  depict  some  of  the  Training  and  Readiness  Manual  Tasks  that  a  unit  is  ex¬ 
pected  to  demonstrate  on  R400.  The  majority  of  these  R400  T&R  tasks  are  at  the  6000 
level  (company)  or  5000  level  (platoon  or  section).  These  are  generally  higher  level  tasks 
that  are  applicable  to  larger  units.  The  performance  standards  listed  within  each  T&R  task 
reflect  as  such. 

While  these  T&R  tasks  provide  standards  for  the  performance  of  larger  military  units,  the 
first  step  for  simulation  developers  should  be  to  validate  the  actions  of  individuals  and 
small  units.  Validating  the  behavior  of  automated  forces  is  a  difficult  task.  Fortunately, 
two  methods  are  available  to  aid  in  this  task.  The  first  way  to  evaluate  the  performance  of 
certain  actions  is  with  the  T&R  manual.  After  a  high  level  task  to  be  evaluated  has  been 
selected,  one  locates  the  task  within  the  T&R  manual  and  identifies  this  task’s  “chained 
events.”  Chained  events  are  tasks  which  are  related  to  the  high  level  task,  but  are  often 
performed  by  lower  echelon  military  units.  This  process  can  be  repeated  until  the  evaluator 
locates  a  task  which  is  to  be  performed  by  small  units  or  individuals.  These  lower  level 
tasks  often  provide  detailed  performance  instructions  or  standards.  When  combined  with 
the  conceptual  information  provided  by  higher  level  T&R  tasks,  this  technique  can  be  a 
valuable  tool  for  the  validation  of  automated  human  behavior. 


Infantry 

INF-MAN- 6001 

Conduct  a  Ground  Attack 

INF-MAN- 62 08 

Conduct  obstacle  breaching 

INF-MAN-6217 

Employ  Scout  Snipers 

INF-ASLT-5001 

Provide  Direct  Fires 

INF-ASLT-5002 

Occupy  Firing  Positions 

INF-MGUN-5001 

Provide  Offensive  Fires 

INF-MGUN-5002 

Occupy  Firing  Positions 

INF-MORT-5001 

Provide  Indirect  Fires 

INF-MORT-5002 

Occupy  a  Mortar  Position 

Assault 

INF-ASLT-5001 

Provide  Direct  Fires 

INF-ASLT-5002 

Occupy  Firing  Positions 

Figure  5.3:  Range  400  Training  &  Readiness  Tasks  1,  from  [47] 
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Command  and  Control 

INF-C2-6007 

Execute  Command  and  Control  of  an  Operation 

Combat  Service  Support 

INF-CSS-6002 

Process  Casualties 

Fire  Support 

INF-FSPT-6006 

Conduct  Fire  Support  Team  (FiST)  Operations 

Intelligence 

INF-INT-6002 

Conduct  Intelligence  Collections 

Engineer 

1371-MOBL-2025 

Perform  manual  breaching 

1371-MOBL-2016 

Conduct  obstacle  breaching  operations 

1371-MOBL-1003 

Breach  explosive  obstacles/hazards 

1371-MOBL-2015 

Employ  the  APOBS 

1371-DEMO-2004 

Compute  the  Net  Explosive  Weight  (NEW) 

1371-DEMO-2005 

Take  appropriate  protective  measures 

Figure  5.4:  Range  400  Training  &  Readiness  Tasks  2,  from  [47] 

The  second  method  for  evaluating  the  performance  of  units  is  with  assessment  documents 
such  as  the  TTECG-produced  R400  Handbook.  Because  of  the  frequency  with  which  units 
conduct  training  at  R400  and  the  serious  nature  of  the  evaluation,  specialized  assessment 
sheets  have  been  produced  for  the  TTECG  exercise  controllers.  These  assessment  sheets 
organize  the  numerous  aspects  of  R400  into  a  sensible  manner  and  highlight  the  key  con¬ 
cepts  that  a  unit  must  display  in  order  to  be  successful.  TTECG  describes  these  documents 
as  “an  extension  of  the  T&R  standard[s]”  and  while  they  are  not  official  military  doctrine, 
they  provide  valuable  guidance  for  conducting  a  ground  attack  that  encompasses  “current 
and  relevant  techniques,  procedures  and  best  practices”  [47,  p.  19].  With  this  in  mind,  it  is 
important  to  note  that  these  assessment  sheets  should  not  only  be  used  in  the  validation  of 
automated  tactical  behavior,  but  should  also  be  considered  by  simulation  developers  when 
they  are  developing  tactical  behaviors. 

5.3  Description  of  a  Typical  Range  400  Exercise  Force 

The  standard  force  to  execute  an  attack  on  R400  is  a  reinforced  rifle  company.  This  or¬ 
ganization  consists  of  a  full  infantry  rifle  company,  as  well  as  attachments  from  different 
organizations 

A  standard  rifle  company  is  divided  into  several  elements.  The  main  subunits  include  three 
rifle  platoons  and  one  weapons  platoon.  Each  rifle  platoon  is  led  by  a  platoon  commander 
and  a  platoon  sergeant;  the  rifle  platoons  are  themselves  subdivided  into  three  rifle  squads. 
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Rifle  squads  are  led  by  a  squad  leader  and  are  subdivided  into  three  fire  teams  of  four 
Marines  each.  The  members  of  each  fire  team  include  a  team  leader,  automatic  rifleman, 
assistant  automatic  rifleman,  and  a  rifleman.  The  automatic  rifleman  is  an  important  mem¬ 
ber  of  the  team  because  of  the  firepower  he  provides.  If  the  automatic  rifleman  were  to 
become  a  casualty,  another  team  member  would  assume  use  of  the  automatic  rifleman’s 
primary  weapon  system  at  the  earliest  possible  opportunity. 

An  infantry  company’s  weapons  platoon  consists  of  three  sections  capable  of  employing 
60mm  mortars,  rockets,  and  medium  machine  guns.  The  60mm  mortar  section  is  respon¬ 
sible  for  the  care  and  operation  of  three  mortar  systems.  The  section  is  led  by  a  section 
leader  and  is  comprised  of  three  mortar  squads,  each  of  which  contains  three  Marines.  The 
mortar  section  usually  operates  as  an  independent  unit  in  support  of  the  company,  however 
individual  squads  can  be  assigned  to  infantry  platoons  in  order  to  conduct  close  range  fire 
missions.  The  assault  section  is  responsible  for  employing  the  shoulder-launched  multi¬ 
purpose  assault  weapon  (SMAW),  and  conducting  breaching  operations  through  the  use  of 
various  demolition  charges.  The  section  includes  a  total  of  13  Marines  and  six  SMAWs. 
They  are  led  by  a  section  leader  and  divided  into  three  assault  squads  consisting  of  four 
Marines  each.  During  combat  operations,  these  units  are  usually  attached  to  rifle  platoons 
which  have  need  of  an  assault  squad’s  specialized  capabilities.  The  medium  machine  gun 
section  consists  of  22  Marines  and  six  M240B  medium  machine  guns.  They  are  led  by  a 
section  leader  and  divided  into  three  machine  gun  squads.  Each  squad  consists  of  seven 
Marines,  is  led  by  a  squad  leader,  and  is  subdivided  into  two  machine  gun  teams.  Each  ma¬ 
chine  gun  team  includes  a  team  leader,  a  gunner,  and  an  ammunition  man.  Though  these 
units  can  operate  in  a  variety  of  ways,  machine  guns  squads  will  rarely  be  split  into  separate 
teams. 

One  of  the  main  goals  of  R400  is  to  test  a  company’s  ability  to  integrate  its  organic  capa¬ 
bilities  with  numerous  reinforcements.  These  non-organic  forces  typically  include  an  en¬ 
gineer  squad,  a  heavy  machine  gun  section,  a  81mm  mortar  section,  a  scout  sniper  squad, 
and  several  forward  observers.  The  engineer  squad  typically  consists  of  approximately 
seven  Marines  who  specialize  in  counter-mobility  and  mobility  (breaching)  techniques. 
The  heavy  machine  gun  section  consists  of  approximately  seven  Marines  and  employs  ei¬ 
ther  two  M2  heavy  machine  guns,  two  Mk-19  automatic  grenade  launchers,  or  a  combina- 
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tion  of  the  two.  Additionally,  these  systems  are  usually  employed  from  the  turret  of  a  high 
mobility  multipurpose  wheeled  vehicle  (HMMWV).  The  81mm  mortar  section  consists 
of  approximately  15  Marines  and  is  responsible  for  employing  four  81mm  mortar  systems. 
The  scout  sniper  squad  includes  four  individuals  who  are  responsible  for  providing  forward 
observation  and  precision  fire  capabilities  to  the  infantry  company. 

The  integration  of  all  of  these  assets  is  the  responsibility  of  the  company  commander,  his 
headquarters  staff,  and  his  fire  support  team  (FiST).  The  FiST  is  a  special  organization 
responsible  for  coordinating  the  employment  of  most  of  the  specialized  weapons  units, 
and  for  deconflicting  their  fires  from  the  maneuvering  rifle  platoons.  The  team  usually 
consists  of  an  artillery  forward  observer  (FO),  an  81mm  mortar  FO,  a  forward  air  controller 
(FAC),  and  several  radio  operators  (ROs).  The  members  of  the  team  organic  to  the  infantry 
company  are  the  FiST  Leader  and  his  RO. 

5.4  Building  a  Scripted  Scenario  of  Range  400 

With  the  simulation  scenario  selected,  the  next  step  is  to  build  a  COMBATXXI  scenario 
that  is  representative  of  an  actual  live  fire  exercise.  For  scenarios  involving  human  behav¬ 
ior,  it  is  recommended  to  “create  the  information  by  hand  first,  then  automate  it  later  if 
necessary”  [29,  p.  43].  The  reason  for  this  is  that  creating  a  scripted  scenario  helps  to 
identify  key  behavior  aspects  that  actual  military  forces  display  on  R400.  These  impor¬ 
tant  behaviors  will  play  a  role  in  the  eventual  creation  of  automated  behavior  mechanisms. 
Also,  by  building  the  target  scenario  using  the  standard  scripted  approach,  insights  can  be 
gained  into  the  limitations  of  this  approach.  The  following  discussion  is  based  on  the  actual 
implementation  of  the  scenario  using  the  scripting  methodology. 

For  demonstration  purposes,  the  size  of  both  friendly  and  enemy  forces  will  be  scaled  down. 
This  step  allows  simulation  developers  to  focus  their  attention  on  selected  tactical  actions. 
These  actions  will  be  recreated  in  COMBATXXI  using  standard  development  techniques. 
Difficulties  in  the  scenario  creation  process  and  challenges  to  scenario  reusability  will  be 
identified  and  addressed. 

Marine  forces  within  this  scenario  will  consist  of  two  infantry  rifle  squads  and  one  infantry 
machine  gun  squad.  The  rifle  squads  will  be  referred  to  as  first  squad  and  second  squad. 
The  machine  gun  squad  will  be  referred  to  as  such.  These  forces  will  be  attacking  an  enemy 
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fireteam  that  is  defending  the  western  trenches  of  R400.  First  the  machine  gun  squad  will 
move  to  a  support  by  fire  position  on  Machine  Gun  Hill,  and  then  will  begin  suppressing 
enemy  positions.  The  rifle  squads  will  utilize  this  suppression  to  maneuver  on  the  enemy 
positions.  Order  of  movement  will  be  second  squad,  followed  by  first  squad.  It  should 
be  noted  that  because  of  the  elevation  of  Machine  Gun  Hill,  infantry  forces  are  permitted 
to  cross  underneath  the  machine  gun  fire.  When  second  squad  reaches  the  squad  release 
point,  they  will  establish  a  support  by  fire  position  from  which  they  will  suppress  enemy 
positions.  During  this  time  period,  the  responsibility  of  suppressing  enemy  positions  will 
pass  from  the  machine  gun  squad  to  second  squad.  Once  second  squad  has  established  an 
effective  base  of  fire,  first  squad  will  continue  maneuvering  to  its  assault  position  which  is 
just  to  the  west  of  the  enemy.  Under  the  cover  of  second  squad’s  support  by  fire  position, 
first  squad  will  assault  through  the  enemy  position,  and  continue  to  their  limit  of  advance. 
When  the  limit  of  advance  has  been  reached,  first  squad  will  consolidate  in  a  defensive 
position  to  the  north  of  the  western  trenches.  Second  squad  and  the  machine  gun  squad 
will  consolidate  in  a  defensive  position  to  the  north  of  the  enemy  command  post. 

Chapter  4  discusses  important  principles  which  are  utilized  in  the  conduct  of  military  opera¬ 
tions.  Unfortunately,  the  correct  implementation  of  the  simple  combat  operation  described 
in  the  attack  case  study  encompasses  many  complex  tactical  actions  that  are  difficult  to 
achieve  through  automated  behavior  algorithms.  To  scope  the  efforts  of  this  thesis,  the 
decision  has  been  made  to  concentrate  on  replicating  the  security  formations  that  military 
units  use  during  the  course  of  tactical  operations. 

5.5  Scenario  Security  Formations 

Before  commencement  of  an  attack,  military  units  conduct  several  standardized  actions. 
One  of  the  first  considerations  is  security.  If  a  unit  is  staging  for  an  attack  from  inside  a 
friendly  base,  then  that  base  can  be  assumed  to  provide  security.  However,  if  the  unit  is 
staging  outside  of  friendly  lines,  then  a  portion  of  the  unit  must  be  devoted  to  providing 
security.  A  360  degree  security  perimeter  is  a  standard  formation  used  to  accomplish  this 
requirement. 

While  this  may  appear  to  be  a  relatively  simple  action,  establishing  360  degree  security 
requires  actual  military  units  to  consider  numerous  factors  regarding  friendly  capabilities, 
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enemy  threats,  and  terrain  characteristics.  Accomplishing  these  tasks  within  a  simulation  is 
an  even  more  complicated  process.  Within  COMBATXXI,  there  is  no  standard  command 
or  template  to  use  when  creating  a  security  formation.  To  create  a  security  formation,  the 
scenario  developer  must  do  so  using  COMBATXXI  primitive  orders,  compound  orders,  and 
control  measures.  It  is  important  to  recognize  that  unit  security  is  an  ongoing  task  that  must 
be  accomplished  before,  during,  and  after  tactical  operations.  Figure  5.5  and  Figure  5.6 
illustrate  T&R  manual  standards  for  creating  security  formations.  The  following  security 
formations  were  utilized  in  the  R400  scenario: 

Formation  1:  Prior  to  the  attack.  360  degree  security  formation  comprised  of  the  entire 
unit.  Machine  gun  squad  is  integrated  into  the  formation  and  they  are  oriented  toward 
the  enemy  and  along  a  high  speed  avenue  of  approach  (a  road). 

Formation  2:  Prior  to  the  attack.  360  degree  security  formation  in  which  most  of  the  unit 
has  been  pulled  into  the  center  in  order  to  conduct  pre-combat  checks  and  inspec¬ 
tions.  Designated  members  of  the  unit  occupy  guardian  angel  positions  in  order  to 
provide  360  degree  security  for  the  unit. 

Formation  3:  During  the  attack.  360  degree  security  formation  comprised  solely  of  the 
machine  gun  squad.  After  the  machine  gun  squad  finishes  their  support  by  fire  mis¬ 
sion,  they  set  up  a  small  security  formation  at  the  base  of  Machine  Gun  Hill,  and  then 
prepare  to  relocate  to  their  final  consolidation  position. 

Formation  4:  After  the  attack.  180  degree  security  formation  consisting  of  an  infantry 
squad.  After  assaulting  through  their  objective  and  reaching  their  limit  of  advance, 
the  first  squad  sets  a  1 80  degree  security  perimeter  that  is  oriented  in  the  direction  of 
a  likely  enemy  counterattack. 

Formation  5:  After  the  attack.  180  degree  security  formation  consisting  of  an  infantry 
squad  and  the  machine  gun  squad.  After  second  squad  has  finished  its  support  by  fire 
mission,  it  moves  to  a  location  just  north  of  the  enemy  command  post.  Once  there, 
it  sets  up  a  180  degree  security  perimeter  that  is  oriented  in  the  direction  of  a  likely 
enemy  counterattack.  The  machine  gun  squad  has  been  designated  to  join  second 
squad  in  this  formation,  however  their  arrival  is  delayed.  In  order  to  account  for  this, 
second  squad  positions  its  forces  to  cover  the  entire  sector.  Once  the  machine  gun 
squad  arrives  at  the  position,  they  assume  defensive  positions  that  suit  the  capability 
of  their  primary  weapon  systems  (firing  along  the  long  access  of  a  high  speed  avenue 
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INF-MAN-4201 :  Conduct  assembly  area  actions  (D) 

SUPPORTED  MET (S) :  2 

EVALUATION-CODED :  NO  SUSTAINMENT  INTERVAL:  6  months 

condition :  Given  a  unit,  an  order,  remote  likelihood  of  enemy  contact,  and 
in  preparation  for  follow  on  operations. 

STANDARD :  To  accomplish  the  mission,  meet  the  commander's  intent,  and 
prepare  for  follow  on  operations. 

EVENT  COMPONENTS: 

1.  Establish  and  improve  all  around  security.  (S) 

2.  Position  automatic  weapons  on  most  likely  avenues  of  enemy  approach.  (A) 

3.  Improve  fields  of  fire,  obstacles,  fire  support  plan.  (F) 

4.  Establish  and  improve  positions/entrenchment.  (E) 

5.  Conduct  planning. 

6.  Conduct  resupply. 

7.  Prepare  for  combat  operations. 

REFERENCES: 

1.  MCWP  3-11.1  Marine  Rifle  Company/  Platoon 

2.  MCWP  3-11.2  w  chi  Marine  Rifle  Squad 


Figure  5.5:  Pre-Operation  Security  T&R  Task,  from  [46] 


INF-MAN-4205:  Consolidate  f D1 

SUPPORTED  MET (S) :  2 

EVALUATION-CODED :  NO  SUSTAINMENT  INTERVAL:  6  months 

CONDITION :  Given  a  unit,  an  order,  and  in  preparation  for  follow  on 

operations . 

STANDARD :  To  enable  preparation  for  combat  while  maintaining  security, 
reorganizing  the  unit,  and  improving  the  current  position. 

EVENT  COMPONENTS: 

1.  Establish  and  improve  all  around  security.  (S) 

2.  Execute  command  and  control. 

3.  Displace  or  reposition  elements  as  required. 

4.  Position  automatic  weapons  on  most  likely  avenues  of  enemy  approach.  (A) 

5.  Process  ammunition,  casualty,  and  equipment  (ACE)  reports. 

6.  Redistribute  ammunition,  personnel,  supplies,  and  equipment. 

7.  Conduct  CASEVAC/MEDEVAC  as  required. 

B.  Detain/process  detainees  as  required. 

9.  Conduct  information  collections. 

10.  Improve  fields  of  fire/sectors  of  fire,  obstacles,  etc.  (F) 

11.  Establish/improve  positions/entrenchment.  (E) 

12.  Prepare  for  follow-on  operations. 


Figure  5.6:  Post-Operation  Security  T&R  Task,  from  [46] 


of  approach).  Additional  members  of  second  squad  assume  an  alternate  position 
(flank  security). 

While  it  appears  to  be  a  relatively  simple  process,  the  creation  of  a  security  formation  en¬ 
compasses  numerous  factors  that  do  not  easily  translate  from  an  actual  Marine  in  the  field, 
to  an  entity  in  a  simulation.  These  factors  include  analyzing  the  terrain  in  which  a  unit  is 
situated,  the  unit’s  mission  and  capabilities,  and  the  perceived  enemy  threat.  The  following 
sections  describe  the  steps  required  to  create  a  security  formation  within  COMBATXXI. 
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5.6  Security  Formation  Creation  Process 

When  creating  a  security  formation  for  COMBATXXI  entities,  a  circle  formation  (or  a 
formation  that  is  close  to  a  circle)  that  provides  360  degree  coverage  is  a  logical  place  to 
start.  Assigning  sectors  of  responsibility  is  one  of  the  first  issues  that  the  scenario  developer 
encounters.  To  accomplish  this  task,  the  scenario  developer  must  consider  the  overall  size 
of  the  unit,  the  number  of  subunits,  and  the  number  of  personnel  within  each  subunit.  If 
all  of  the  subunits  have  the  same  number  of  personnel  and  contain  the  same  capabilities, 
the  area  of  responsibility  for  each  subunit  can  be  found  by  dividing  360  by  the  number  of 
subunits.  This  is  a  simplifying  assumption  that  can  be  made  initially,  however  the  scenario 
developer  must  remember  that  this  will  not  always  be  the  case. 

The  next  step  is  determining  the  overall  size  of  the  security  formation.  This  step  is  depen¬ 
dent  upon  the  number  of  personnel  participating  in  the  security  formation  and  the  dispersion 
between  each  entity.  A  standard  dispersion  amount  can  be  found  in  military  publications, 
however  the  scenario  developer  must  consider  special  circumstances  that  could  cause  a  unit 
to  alter  its  dispersion.  Heavily  forested  terrain  that  limits  visibility  can  cause  a  unit  to  lower 
it  dispersion,  as  can  missions  requiring  a  unit  to  avoid  detection  by  enemy  forces.  Alterna¬ 
tively,  open  terrain  such  as  a  desert,  or  the  existence  of  a  heavy  enemy  indirect  fire  threat 
could  cause  a  unit  to  use  an  increased  amount  of  dispersion. 

Once  subunit  area  of  responsibility  and  overall  formation  size  has  been  determined,  the 
scenario  developer  can  create  waypoints  which  represent  each  subunit’s  location.  To  get 
each  subunit  into  its  proper  position,  a  compound  order  must  be  created  for  each  of  these 
waypoints.  Compound  orders  are  comprised  of  one  or  more  primitive  orders.  Commonly 
used  primitive  orders  include  the  following: 

•  MOVE_TO_POINT 

•  CHANGE_FORMATION 

•  CHANGE_POSTURE 

•  CHAN  GE_ORIENTATION 

•  STOP_MOVING. 

It  is  the  scenario  developer’s  responsibility  to  create  a  sequence  of  primitive  orders  which 
will  ultimately  place  a  subunit  in  the  correct  position.  One  of  the  first  challenges  is  getting 
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a  unit  to  assume  a  proper  formation.  The  CHANGE_FORMATION  primitive  order  allows 
the  scenario  developer  to  choose  from  numerous  standardized  formations  which  can  result 
in  a  reasonable  overall  security  formation.  However,  if  the  scenario  developer  wants  each 
subunit  to  maintain  the  appropriate  amount  of  dispersion,  and  for  each  subunit’s  flanks  to 
be  linked  to  the  adjacent  subunit’s  flanks,  the  scenario  developer  will  likely  have  to  create 
a  new  formation.  This  is  accomplished  by  using  the  Scenario  Integration  Tool  Suite  (SITS) 
formation  editor.  This  tool  allows  the  scenario  developer  to  specify  the  number,  location, 
and  orientation  of  entity  positions  within  a  formation. 

Once  a  proper  formation  has  been  designated,  the  next  task  involves  moving  the  unit  to 
its  intended  location,  getting  the  formation  oriented  properly,  and  getting  individual  en¬ 
tities  oriented  in  the  proper  direction.  This  is  accomplished  by  adding  more  primitive 
orders  to  the  subunit’s  compound  order.  The  simplest  way  to  accomplish  this  (after  us¬ 
ing  the  CHANGE_FORMATION  command)  is  to  move  the  subunit  to  their  location  using 
MOVE_TO_POINT,  order  the  unit  to  halt  with  STOP_MOVING,  and  then  getting  the  unit 
to  look  in  the  proper  direction  by  using  CHANGE_ORIENTATION.  This  is  a  simple  set  of 
commands  which  can  be  easily  created,  however  several  problems  exist.  First,  even  though 
the  individual  members  of  the  subunit  will  be  facing  in  the  proper  direction,  the  overall 
orientation  of  the  subunit’s  formation  is  likely  incorrect.  This  means  that  instead  of  having 
a  line  of  entities  which  stretches  from  east  to  west,  the  simulation  could  easily  create  a 
column  of  entities  which  stretch  from  north  to  south.  This  mistake  could  seriously  impact 
the  subunit’s  mission  effectiveness  by  limiting  the  number  of  entities  able  to  engage  enemy 
forces  (especially  if  the  subunit  is  positioned  on  rolling  terrain)  and  by  making  the  subunit 
more  vulnerable  to  enemy  fire  (machine  gunners  prefer  to  engage  targets  by  firing  along 
the  long  axis  of  a  column).  One  method  devised  to  avoid  this  problem  involves  the  creation 
of  an  intermediate  waypoint  that  the  subunit  must  pass  through  prior  to  arriving  at  its  final 
position.  This  intermediate  waypoint  should  be  positioned  so  that  the  direction  from  this 
point  to  the  final  position  corresponds  to  the  desired  orientation  of  the  subunit’s  formation. 
An  example  of  this  technique  for  a  semi-circular  formation  is  illustrated  in  Figure  5.7. 

Though  this  technique  complicates  many  of  the  compound  orders  that  must  be  created,  it 
also  offers  simple  solutions  to  two  additional  problems.  The  first  problem  is  that  when  units 
arrive  at  their  final  destination,  they  are  often  out  of  formation.  As  discussed  earlier,  forma- 
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Figure  5.7:  Waypoints  Needed  for  a  Scripted  Security  Formation 


tion  problems  can  limit  a  unit’s  effectiveness  or  make  them  more  vulnerable  to  enemy  fire. 
This  problem  can  be  avoided  by  adding  using  the  CHANGE_FORMATION  command  after 
the  subunit  moves  to  the  intermediate  waypoint.  This  is  useful  even  if  the  subunit  is  already 
in  the  desired  formation  because  it  forces  the  subunit  to  correct  formation  deficiencies  one 
last  time  before  they  move  to  their  final  position.  The  next  problem  that  the  intermediate 
waypoint  technique  helps  with  is  the  orientation  of  the  subunit  entities.  This  step  can  be 
accomplished  by  using  the  CHANGE_ORIENTATION  command.  However  this  technique 
forces  the  scenario  designer  to  calculate  and  manually  input  the  appropriate  orientations 
for  every  subunit  within  a  formation.  This  can  be  a  time  intensive  process  if  a  unit  contains 
many  subunits.  Additionally,  the  work  must  be  repeated  for  each  subunit  if  the  overall 
unit’s  orientation  or  composition  changes.  By  using  the  intermediate  waypoint  technique, 
the  scenario  developer  can  avoid  using  the  CHANGE_ORIENTATION  command  as  long 
as  the  direction  from  the  intermediate  waypoint  to  the  final  position  corresponds  to  the  di¬ 
rection  that  the  entities  should  be  observing.  This  saves  time  by  simplifying  the  compound 
orders  and  enables  the  scenario  developer  to  quickly  adjust  the  intended  orientation  of  the 
forces  by  moving  the  waypoint  locations  within  SITS. 

Once  the  compound  orders  for  each  security  position  have  been  created,  the  actions  they 
describe  are  enacted  through  coordinated  maneuver  orders  and  behaviors.  This  provides 
a  relatively  straightforward  approach  for  creating  a  basic  security  formation.  If  a  unit  is 
composed  of  subunits,  this  may  require  the  creation  of  numerous  compound  orders  and 
behaviors.  The  COMBATXXI  Maneuver  Tool  can  help  manage  the  complexity  involved 
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in  invoking  these  orders,  however  they  still  must  be  individually  produced  by  scenario 
developers.  If  a  scenario  developer  desires  to  ensure  the  suitability  of  such  formations  in 
more  complicated  situations,  additional  factors  need  to  be  considered. 


5.7  Advanced  Considerations  for  Security  Formations 

Creating  security  formations  within  COMBATXXI  that  are  representative  of  actual  military 
security  formations  requires  the  scenario  developer  to  consider  several  additional  factors, 
and  then  modify  the  basic  security  formation  accordingly.  For  short  security  halts,  subunits 
will  quickly  be  assigned  sectors  of  responsibility  that  are  appropriate  to  the  subunit’s  size. 
If  a  unit  intends  to  occupy  a  location  for  a  longer  period  of  time,  security  positions  will  be 
tailored  to  match  the  combat  capabilities  of  each  subunit.  One  way  this  is  accomplished  is 
by  adjusting  sectors  of  responsibility  to  match  each  subunit’s  capabilities.  Within  standard 
security  formations,  standard  riflemen  can  be  expected  to  spread  out  and  cover  the  sector 
of  fire  that  has  been  assigned  to  their  fire  team.  This  is  not  the  case  for  special  units  such  as 
medium  machine  gun  teams.  The  primary  mission  of  the  machine  gun  team’s  members  is  to 
ensure  the  effective  employment  of  their  machine  gun.  This  involves  a  different  formation 
than  that  practiced  by  standard  riflemen.  For  a  medium  machine  gun  team,  this  typically 
means  that  the  gunner  and  the  team  leader  will  be  co-located  at  the  machine  gun.  The  third 
person  of  the  team,  the  ammunition  man,  will  cover  an  alternate  sector  of  fire  in  order  to 
protect  the  gunner  and  the  team  leader.  As  long  as  there  are  riflemen  nearby  to  support  the 
machine  gun  team,  the  ammunition  man  will  not  be  the  only  person  assigned  to  cover  this 
sector  of  fire.  This  is  important  because  during  an  engagement,  the  ammunition  man  must 
be  free  to  move  in  order  to  prepare  ammunition  boxes,  or  to  assume  an  alternate  role  if  his 
team  suffers  casualties.  Finally,  machine  gun  teams  will  typically  operate  in  pairs,  and  will 
be  called  a  machine  gun  squad.  This  task  organization  increases  the  chances  that  at  least 
one  team  will  be  able  to  provide  suppressive  fires  in  support  of  an  assigned  mission.  This 
technique  was  utilized  in  several  of  the  scenario’s  security  formations. 

The  previous  paragraph  describes  how  different  types  of  subunits  fit  together  in  a  security 
formation.  The  next  major  requirement  involves  deciding  how  to  position  subunits  within 
a  formation,  and  in  what  concentrations.  The  unit  mission,  enemy  threat,  and  terrain  char¬ 
acteristics  must  be  considered  in  order  to  accomplish  this  task.  A  unit’s  mission  usually 
includes  an  assigned  sector  of  responsibility.  This  sector  could  range  in  size  from  a  very 
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narrow  sector  assigned  to  an  individual  entity  (such  as  in  an  urban  environment),  to  a  360 
degree  perimeter  that  an  entire  unit  must  cover.  Within  such  a  sector,  subunits  will  often 
position  themselves  in  locations  that  maximize  their  primary  weapon  system’s  effective¬ 
ness,  and  provide  the  most  resistance  to  enemy  threats.  Examples  of  this  include  placing 
assault  units  with  rocket  launchers  near  roads  that  enemy  vehicles  may  utilize,  and  placing 
machine  gunners  in  locations  that  allow  them  to  engage  targets  at  extended  ranges  or  to 
employ  grazing  fire  techniques  (machine  gun  fire  along  flat  terrain  that  is  no  more  than 
one  meter  above  ground).  This  technique  was  accomplished  in  Formation  5  by  placing  the 
machine  gun  squad  along  the  long  axis  of  a  road  that  could  serve  as  a  high  speed  enemy 
avenue  of  approach.  The  desire  to  properly  position  more  powerful  weapons  systems  is 
also  applicable  to  the  automatic  rifleman  within  a  standard  infantry  fire  team.  By  doctrine, 
all  members  of  a  fire  team  are  supposed  to  be  assigned  a  single  sector  of  fire  (note  this  is  not 
always  possible  due  to  personnel  shortages).  Within  a  fire  team’s  assigned  area,  the  auto¬ 
matic  rifleman  must  be  positioned  so  that  he  can  cover  the  team’s  entire  sector  of  fire.  This 
is  an  important  step  within  military  operations,  however  this  action  was  not  programmed 
within  the  scripted  scenario. 

The  unit’s  mission  and  the  terrain  in  which  they  are  situated  are  major  factors  in  how  entities 
are  positioned.  One  complaint  of  AI  controlled  entities  is  that  they  will  position  themselves 
next  to  a  wall  or  terrain  feature  that  severely  limits  their  observation  capabilities.  This  is 
often  cited  as  a  lack  of  realism  in  games  and  simulations.  To  overcome  this  deficiency,  the 
scenario  developer  must  consider  the  amount  of  observation  that  a  unit  requires  to  execute 
its  mission,  and  then  locate  suitable  positions  within  available  terrain.  Some  reconnaissance 
or  forward  observer  units  will  want  to  be  able  to  see  as  far  as  possible.  Regular  combat 
units  usually  desire  to  see  as  far  as  their  weapons  systems  can  effectively  engage  enemy 
forces.  At  other  times,  units  will  want  to  ensure  the  enemy  does  not  observe  their  forces  and 
will  therefore  remain  behind  a  terrain  feature,  even  if  it  limits  their  ability  to  employ  their 
weapons  systems.  To  accomplish  any  of  these  goals,  the  scenario  developer  must  place  a 
waypoint  at  a  location  on  the  map,  and  then  use  the  SITS  LOS  tool  to  ensure  the  location 
provides  appropriate  observation.  This  step  was  accomplished  for  every  unit  location  in  the 
scenario. 

One  final  consideration  concerns  the  actual  number  of  entities  that  are  actively  providing 
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security,  and  the  state  of  these  members.  It  is  important  to  recognize  that  not  every  member 
in  a  unit  will  hold  a  position  on  the  outer  edge  of  the  security  formation.  This  is  especially 
true  for  unit  leaders  and  mortarmen.  In  most  circumstances,  these  entity  types  will  estab¬ 
lish  their  own  positions  inside  the  formation  that  allow  them  to  perform  their  leadership 
responsibilities  or  allow  them  to  effectively  employ  their  primary  weapon  systems.  This 
was  illustrated  in  Formation  2  when  a  portion  of  the  unit  was  brought  inside  the  security 
formation  so  that  they  could  conduct  their  attack  preparations,  while  another  portion  of  the 
unit  continued  to  maintain  360  degree  security.  The  state  of  the  entities  on  the  formation 
must  also  be  considered.  When  Marines  occupy  security  positions,  they  generally  assume 
the  prone  position  in  order  to  limit  their  exposure  to  enemy  fire.  Within  COMBATXXI, 
this  can  be  accomplished  by  using  the  CHANGE_POSTURE  primitive  order  within  every 
subunit’s  compound  order  for  movement.  For  additional  realism,  one  should  recognize  that 
when  a  unit  is  set  in  a  fighting  position  for  an  extended  amount  of  time,  not  every  member 
will  be  actively  observing.  General  readiness  levels  for  units  occupying  defensive  positions 
for  an  extended  amount  of  time  are  50%  during  the  day  and  25%  at  night.  This  aspect  could 
be  represented  in  COMBATXXI  by  turning  off  the  sensors  of  specified  entities. 


5.8  Challenges  to  Overcome 

The  previous  instructions  and  guidance  enable  a  scenario  developer  to  create  security  for¬ 
mations  which  are  fairly  representative  of  what  takes  place  in  actual  combat.  Potential 
critiques  of  the  example  scenario  include  the  large  number  of  compound  orders  and  way- 
points  which  must  be  created  and  positioned  in  order  to  achieve  this  behavior.  One  method 
that  attempts  to  avoid  this  problem  is  changing  the  fidelity  of  the  subunits.  Within  this 
scenario,  subunits  were  created  to  represent  each  fire  team;  the  number  of  compound  or¬ 
ders  and  waypoints  could  be  reduced  by  designating  the  squad  as  the  lowest  subunit  in  the 
simulation.  Unfortunately  this  approach  has  two  disadvantages.  First,  the  scenario  devel¬ 
oper  must  now  create  additional  squad  formations  that  will  place  entities  into  their  proper 
security  formation  positions.  Depending  on  the  scenario,  this  may  or  may  not  reduce  the 
overall  scenario  designer  workload.  A  second  problem  is  that  this  technique  does  not  scale 
well.  Within  scenarios  with  large  number  of  units,  scenario  designers  using  squads  as  the 
lowest  subunit  will  face  the  same  level  of  complexity  as  within  the  example  scenario  which 
used  fire  teams  as  the  lowest  subunit. 
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The  final  and  potentially  largest  problem  concerns  how  a  unit  deals  with  casualties.  If  a 
security  formation  is  created  in  the  middle  of  a  scenario,  the  unit  must  be  able  to  account 
for  casualties  taken  in  previous  engagements,  and  adjust  the  security  formation  so  that  no 
gaps  exist.  Limited  functionality  exists  to  deal  with  this  problem.  Within  the  example 
scenario,  if  a  fire  team  is  destroyed,  subsequent  unit  security  formations  will  contain  gaps. 
As  mentioned  before,  one  potential  solution  calls  for  making  the  smallest  subunit  to  be  a 
squad  instead  of  a  fire  team.  By  prioritizing  the  positions  within  a  formation,  the  scenario 
developer  can  help  prevent  major  gaps  from  appearing  in  a  unit’s  overall  formation.  Un¬ 
fortunately  this  does  not  account  for  the  changing  priorities  that  a  unit  will  experience  as 
its  numbers  and  capabilities  change.  While  feasible  for  the  scenario  developer  to  create 
multiple  formation  that  would  enable  effective  operations  for  units  of  different  sizes,  this 
has  the  potential  to  create  an  extremely  large  amount  of  work.  Furthermore,  this  solution 
does  not  scale  to  large  levels;  all  of  these  efforts  would  have  to  be  repeated  if  the  lowest 
subunit  were  changed  to  a  platoon  instead  of  a  squad. 

These  problems  lead  to  one  of  the  fundamental  issues  that  must  be  addressed:  the  ability 
to  organize  subunits  so  that  their  compositions  are  appropriate  to  the  situation,  and  the 
ability  to  assign  each  subunit  a  task  that  is  appropriate  to  its  capabilities.  Examples  of 
programs  displaying  this  functionality  were  illustrated  in  Chapter  3.  These  examples  will 
be  used  as  inspiration  during  the  development  of  dynamic  behavior  capabilities  for  use  in 
COMBATXXI. 
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CHAPTER  6: 

Dynamic  Behavior  Development  and  Demonstrations 


COMBATXXI  is  a  robust  simulation  capable  of  providing  insights  into  military  opera¬ 
tions.  However,  scenario  designers  face  several  challenges  in  the  areas  of  scenario  cre¬ 
ation  and  reusability.  Chapter  5  described  the  behavior  definition  process  for  a  standard 
COMBATXXI  scenario.  For  this  scenario,  a  large  amount  of  work  was  required  to  create 
relatively  basic  infantry  actions.  The  purpose  of  this  chapter  is  to  document  efforts  to  ease 
the  COMBATXXI  behavior  definition  process  by  leveraging  the  new  dynamic  behavior 
methodology  developed  at  the  Naval  Postgraduate  School  (NPS). 

6.1  Scoping  a  Behavior  to  Develop 

The  first  problem  concerns  the  large  amount  of  effort  required  to  create  a  sequence  of  co¬ 
ordinated  tactical  events  which  are  representative  of  actions  conducted  in  actual  combat. 
The  initial  goal  of  this  thesis  was  to  produce  a  scalable  and  reusable  HTN  that  was  ca¬ 
pable  of  coordinating  a  simple  infantry  attack  similar  to  the  one  described  in  Chapter  4. 
However,  a  thorough  task  decomposition  of  the  proposed  attack  behavior  reveals  that  even 
relatively  simple  actions  are  almost  always  composed  of  numerous  pieces.  The  most  basic 
deliberate  attack  can  be  divided  into  the  following  phases,  each  of  which  involves  several 
sub-behaviors. 

1.  Movement  to  Assembly  Area 

2.  Movement  from  Assembly  Area  to  Attack  Position 

3.  Movement  from  Attack  Position  To  Assault  Position 

4.  Actions  on  the  Objective 

5.  Consolidation 

Creating  a  representative  attack  behavior  requires  its  associated  sub-behaviors  to  be  exe¬ 
cuted  at  the  correct  time,  at  the  correct  location,  and  in  the  correct  manner.  This  is  a  task 
that  requires  a  planning  process  capable  of  executing  appropriate  decision  making  based  on 
a  unit’s  situational  awareness  and  its  task  organization.  Inspiration  for  how  such  a  planning 
system  could  be  developed  is  described  in  the  Chapter  3  case  studies. 
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An  important  prerequisite  for  a  planning  system  is  to  correctly  model  the  sub-behaviors 
required  in  the  execution  of  that  action.  To  be  useful  by  an  automated  planner,  these  sub¬ 
behaviors  themselves  must  be  scalable  and  reusable.  One  of  the  impediments  to  the  rapid 
creation  of  scenarios  within  COMBATXXI  is  that  many  of  the  sub-behaviors  do  not  exist. 
This  requires  that  for  each  scenario,  developers  must  create  each  sub-behavior  from  existing 
primitive  behaviors.  Because  such  actions  are  taken  with  specific  scenarios  in  mind,  this 
results  in  the  production  of  scripted  behaviors  that  are  rarely  scalable  or  reusable.  This 
thesis  begins  the  process  of  correcting  this  deficiency  by  constructing  scalable  and  reusable 
sub-behaviors  necessary  for  the  conduct  of  a  basic  attack. 


6.2  Security  Formation  Behavior 

Establishing  a  static  security  formation  was  the  first  behavior  chosen  for  development.  This 
behavior  was  selected  because  it  is  one  that  is  frequently  used  by  ground  combat  forces. 
Major  places  to  employ  security  formations  are  at  the  beginning  and  end  of  an  operation.  In 
practice,  security  formations  will  also  be  employed  periodically  during  other  phases  of  an 
attack.  Examples  of  this  include  having  a  subunit  hold  security  while  the  remainder  of  the 
force  crosses  a  danger  area,  conducting  a  hasty  security  halt  so  that  subunits  can  make  final 
preparations,  and  finally  by  tasking  a  subunit  to  hold  flank  security  so  that  enemy  forces  do 
not  interfere  with  the  assault  element. 

The  establishment  of  a  scalable  and  reusable  behavior  which  is  capable  of  creating  a  secu¬ 
rity  formation  serves  two  purposes.  First,  this  behavior  would  play  an  important  role  for 
AI  planning  systems  that  have  been  tasked  with  creating  an  attack  behavior.  Second,  this 
behavior  could  be  utilized  to  ease  scenario  creation  within  scripted  scenarios  such  as  that 
described  in  Chapter  5. 

Devising  a  scenario-specific  security  formation  for  a  simulated  military  unit  that  is  facing 
a  known  threat  and  is  surrounded  by  a  set  type  of  terrain  is  often  a  straightforward  task. 
Creating  a  generalized  behavior  capable  of  devising  security  formations  that  cover  a  wide 
range  of  friendly,  enemy,  and  terrain  situations  is  a  much  more  difficult  task.  Initial  efforts 
to  create  such  a  behavior  involved  the  use  of  four  core  HTNs.  Figure  6.1  illustrates  the 
relationship  between  these  HTNs. 
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Figure  6.1:  Current  Hierarchy  of  Security  Formation  HTNs 


6.2.1  masterSecurityFormation 

The  first  and  arguably  most  important  HTN  utilized  is  masterSecurityFormation.  This  HTN 
is  responsible  for  receiving  security  formation  parameters  and  then  calculating  the  forma¬ 
tion’s  approximate  location,  geometry,  and  orientation.  While  this  process  itself  can  be 
considered  a  simple  geometry  problem,  the  way  that  masterSecurityFormation  approaches 
this  problem  is  unique  and  therefore  should  receive  special  consideration.  First,  the  HTN 
parameters  include  a  list  of  units  that  are  to  take  part  in  the  security  formation.  This  ap¬ 
proach  enables  multiple  units  to  cooperate  with  each  other  and  ultimately  create  a  single 
tactically  sound  security  formation. 

The  second  item  of  note  concerns  the  fact  that  this  HTN  calculates  preliminary  locations 
for  individual  entities.  This  step  is  necessary  in  order  to  determine  the  overall  formation 
geometry,  and  to  ensure  that  the  formation  accomplishes  the  mission  described  within  its 
assigned  parameters.  However,  it  is  important  to  recognize  that  masterSecurityFormation 
never  assigns  individual  entities  to  occupy  specific  locations.  This  task  is  accomplished 
by  other  HTNs.  While  this  approach  may  seem  artificial,  it  should  be  recognized  that 
this  process  has  parallels  to  actual  military  techniques.  During  reconnaissance  operations, 
military  leaders  often  select  preliminary  individual  positions  so  that  when  the  rest  of  the 
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unit  arrives,  defensive  positions  can  be  occupied  in  a  timely  manner. 

masterSecurityFormation  finishes  by  activating  unitSecurity Formation.  It  does  this  by  as¬ 
signing  unitSecurityFormation  as  a  goal  for  an  individual  entity  in  the  unit  responsible  for 
creating  the  security  formation.  The  primary  parameter  for  this  HTN  consists  of  a  list  of 
individual  security  positions  that  the  unit  has  been  tasked  to  fill.  If  multiple  units  have  been 
tasked  with  creating  one  security  formation,  there  is  a  requirement  to  assign  separate  lists 
to  each  unit.  However,  because  this  step  is  identical  to  one  conducted  within  uni ^Security- 
Formation,  it  is  discussed  in  the  following  subsection. 


6.2.2  unitSecurityFormation 

Once  the  formation’s  general  parameters  have  been  defined,  unitSecurityFormation  is  as¬ 
signed  to  a  single  unit.  It  fulfills  two  important  steps.  First,  it  identifies  the  main  unit’s 
existing  subunits  (if  any  exist)  and  then  analyzes  their  basic  properties.  Based  upon  this 
analysis,  unitSecurityFormation  then  determines  an  appropriate  number  of  individual  se¬ 
curity  positions  for  each  subunit  to  occupy.  As  with  the  previously  described  HTN,  unit¬ 
SecurityFormation  does  not  give  orders  to  individual  entities.  Instead,  the  HTN  gives  gen¬ 
eralized  orders  to  members  of  each  subunit,  and  then  “trusts”  each  of  those  individuals  to 
create  subunit-specific  detailed  plans  which  contribute  to  the  accomplishment  of  the  overall 
mission.  This  is  a  technique  which  is  not  only  consistent  with  military  procedures,  but  is 
also  a  key  aspect  to  HTN  reusability  and  scalability. 

The  next  important  part  of  this  HTN  concerns  how  tasks  are  delivered  to  subunits.  This  pro¬ 
cess  is  carried  out  in  two  ways.  Which  method  is  utilized  depends  upon  whether  or  not  a 
subunit  can  be  broken  down  into  smaller  subunits.  Complex  subunits  are  those  units  which 
themselves  consist  of  multiple  subunits.  Complex  subunits  receive  their  tasks  through  unit¬ 
SecurityFormation.  If  a  subunit  does  not  contain  further  subunits,  it  is  considered  homo¬ 
geneous  or  "simple."  Simple  subunits  are  assigned  their  tasks  through  simpleUnitSecuri- 
tyFormation.  As  with  unitSecurityFormation ,  the  main  parameter  for  simpleUnitSecurity- 
Formation  consists  of  a  list  of  individual  security  positions  that  the  simple  unit  has  been 
tasked  to  occupy. 
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6.2.3  simpleUnitSecurityFormation  and  basicIndividualMove 

The  final  process  of  completing  a  security  formation  is  accomplished  through  a  combina¬ 
tion  of  two  HTNs.  The  first  of  these  HTNs  is  simpleUnitSecurityFormation.  Parameters 
for  this  HTN  include  a  list  of  security  positions  for  which  the  unit  is  responsible.  Unlike 
the  previously  described  HTNs,  simpleUnitSecurityFormation  makes  the  significant  step  of 
assigning  individual  entities  to  occupy  specific  security  positions.  Once  these  assignments 
are  created,  simpleUnitSecurityFormation  assigns  the  basicIndividualMove  HTN  to  each 
entity  in  the  unit  that  is  to  take  part  in  the  security  formation.  basicIndividualMove  is  as¬ 
signed  to  individual  entities  and  its  parameters  encompass  instructions  on  how  to  occupy  a 
specific  security  position.  basicIndividualMove  is  significant  because  unlike  its  predeces¬ 
sors,  this  HTN  causes  simulation  entities  to  take  action.  It  is  also  important  to  recognize 
that  basicIndividualMove  was  designed  to  aid  this  study’s  demonstrations,  and  that  it  does 
not  incorporate  many  of  the  actions  a  real  combatant  would  perform  when  moving  about  a 
battlefield.  The  modular  nature  of  the  security  formation  structure  allows  basicIndividual¬ 
Move  to  be  easily  replaced  by  a  more  representative  movement  control  mechanism.  This 
topic  is  discussed  further  in  Chapter  7. 


6.2.4  Security  Formation  Examples 

Working  together,  the  security  formation  HTNs  provide  scenario  developers  an  intuitive 
and  flexible  tool  for  accomplishing  a  tactical  task  that  is  fundamental  to  military  opera¬ 
tions.  Figure  6.2  illustrates  some  of  the  security  formation  geometries  that  can  be  created 
using  the  exact  same  set  of  unmodified  HTNs  with  different  sets  of  controlling  parameters. 
Several  additional  capabilities  should  also  be  noted: 

•  Dispersion  between  entities  can  be  adjusted  to  suit  the  tactical  situation. 

•  Multiple  units  can  work  together  to  create  one  cohesive  security  formation. 

•  Vehicles  and  entities  with  unique  capabilities  can  be  integrated  into  security  forma¬ 
tions. 

•  Unlike  the  security  formations  described  in  Chapter  5,  each  formation  only  requires 
a  single  waypoint  to  mark  its  location. 

•  Waypoints  can  designate  either  the  center  of  the  formation  (center  and  right  examples 
in  Figure  6.2)  or  the  forward  line  of  troops  (FLOT)  (left  example  in  Figure  6.2). 
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Figure  6.2:  Three  Examples  of  Security  Formations 

Each  of  the  core  HTNs  fulfills  an  important  role  in  accomplishing  the  security  formation. 
The  question  could  be  raised  as  to  why  some  of  these  functions  are  not  combined  into  a 
smaller  number  of  HTNs.  Keeping  these  functions  separate  makes  the  behaviors  modular. 
This  plays  an  important  role  in  the  behavior’s  reusability  and  scalability.  More  importantly, 
it  eases  the  process  of  adding  additional  capabilities  to  the  security  formation  behavior. 

6.3  Affordances 

Once  the  basic  security  formation  behavior  had  been  created,  the  next  step  involved  demon¬ 
strating  its  use  in  tactical  scenarios.  As  described  in  Chapter  3,  embedding  information  into 
terrain  through  the  use  of  affordances  is  a  behavior  control  technique  that  is  widely  used 
in  the  gaming  industry.  This  technique  holds  many  advantages  when  it  comes  to  produc¬ 
ing  basic  tactical  behaviors;  therefore,  it  was  decided  to  develop  such  a  capability  within 
COMBATXXI. 

Affordances,  as  implemented  for  this  thesis,  are  markers  embedded  into  the  terrain  that 
contain  information  relevant  to  that  specific  location,  that  entities  can  use.  Since  the  infor¬ 
mation  may  be  specific  to  a  side  or  constrained  in  some  other  way,  an  access  mechanism 
controls  which  entities  may  access  the  information  or  even  be  aware  of  the  existence  of  the 
affordance.  These  constraints  are  dynamic  and  can  change  over  the  course  of  the  simulation 
run.  Details  of  affordance  functionality  can  be  found  in  Appendix  A.  The  following  test 
scenarios  were  produced  to  demonstrate  the  capabilities  of  the  security  formation  behavior 
and  the  affordance  mechanism. 
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6.4  Urban  Patrol  Demonstration 

The  first  test  of  this  thesis’  products  offered  a  chance  to  demonstrate  both  security  formation 
and  affordance  capabilities.  Specifically,  this  example  highlights  the  diverse  ways  that 
procedural  affordances  can  be  utilized  within  a  scenario.  The  selected  scenario  involved 
an  infantry  Platoon  Commander  and  two  infantry  squads  maneuvering  through  an  urban 
environment.  The  patrol  route  is  depicted  in  Figure  6.3.  This  scenario  also  made  use  of  an 
existing  HTN  called  SquadMove. 

6.4.1  Demonstration  Overview 

The  scenario  begins  when  the  Platoon  Commander  conducts  an  unaccompanied  patrol 
through  the  urban  environment.  This  is  accomplished  through  the  application  of  three 
SquadMove  HTNs  that  are  instantiated  in  the  scenario’s  jump_start  file.  It  should  be  noted 
that  these  movements  are  the  only  scenario  behaviors  activated  through  the  normal  applica¬ 
tion  of  HTNs.  All  remaining  scenario  behaviors  are  triggered  through  the  use  of  procedural 
affordances.  This  approach  is  not  necessarily  the  preferred  way  of  creating  a  COMBATXXI 
scenario,  however  it  was  constructed  in  this  manner  so  as  to  demonstrate  affordance  capa¬ 
bilities. 

As  the  Platoon  Commander  moves  along  the  route,  he  passes  within  range  of  16  procedural 
affordances.  Until  he  reaches  the  final  checkpoint,  the  Platoon  Commander  is  denied  access 
to  all  of  these  affordances  due  to  the  access  constraints  placed  on  them.  When  the  Platoon 
Commander  reaches  the  final  checkpoint,  he  activates  a  series  of  procedural  affordances 
that  cause  the  two  infantry  squads  to  take  action.  First,  the  squads  form  a  single  security 
formation  around  the  initial  waypoint.  After  holding  this  formation  for  a  designated  amount 
of  time,  one  of  the  squads  assembles  in  the  middle  of  the  formation  and  makes  preparations 
to  begin  a  patrol.  When  this  happens,  the  other  squad  readjusts  its  members  so  that  360 
degree  security  is  maintained.  This  process  is  depicted  in  Figure  6.4. 

Next,  the  squads  begin  to  bound  through  the  patrol  route.  When  the  lead  squad  reaches 
a  new  waypoint,  it  establishes  one  of  many  security  formation  types  available  with  mas- 
terSecurity Formation.  Once  this  position  is  set,  the  rear  squad  breaks  down  its  security 
formation,  bounds  through  the  lead  squad’s  position,  and  establishes  a  new  security  forma¬ 
tion  at  the  next  waypoint.  Figure  6.5  illustrates  an  example  of  this  behavior. 
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Figure  6.3:  Patrol  Route  and  Affordances 


This  process  is  continued  until  one  of  the  squads  establishes  a  security  formation  at  the 
final  checkpoint.  At  this  time,  the  rear  squad  also  moves  to  the  final  checkpoint  where  it 
integrates  into  the  existing  security  formation.  This  behavior  is  shown  in  Figure  6.6. 


Figure  6.4:  Removing  a  Unit  from  a  Security  Formation  (From  Left  to  Right) 


6.4.2  Demonstration  Features  to  Note 

Several  behaviors  in  this  demonstration  deserve  special  attention.  Many  of  these  actions 
are  possible  because  of  higher  level  HTNs  designed  to  modify  the  behavior  of  the  primary 
HTNs. 

•  Some  of  the  affordances  trigger  HTNs  that  are  executed  by  the  unit  activating  the  af- 
fordance;  other  affordance  HTNs  are  executed  by  a  unit  that  is  not  the  activating  unit. 
These  actions  were  accomplished  through  the  use  of  higher  level  HTNs  that  were  de¬ 
signed  to  work  with  the  existing  SquadMove  and  masterSecurityFormation  HTNs. 
Examples  of  these  “adapter”  HTNs  include  securityFormationJbyProcessingUnit, 
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Figure  6.5:  Bounding  Past  a  Stationary  Squad 


Figure  6.6:  Reinforcing  an  Existing  Security  Formation 


SqucidMove_MoveDesignatedUnits,  and  SquadMove_OtherU nit  sin  Array  List.  Fig¬ 
ure  6.7  depicts  the  use  of  this  technique. 

•  Removing  a  unit  from  an  existing  security  formation  is  accomplished  through  re- 
moveUnitFromAjfSecForm  which  works  in  conjunction  with  a  procedural  affordance 
that  utilizes  master  Security  Formation . 

•  Adding  a  unit  to  an  existing  security  formation  bears  many  similarities  to  the  process 
of  removing  a  unit.  The  HTN  securityFormation_byPhaseAffordanceMod  accom¬ 
plishes  this  for  arriving  units  by  updating  HTN  parameters  stored  in  ajfordanceUtil- 
ities. 
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•  The  same  scenario  executes  regardless  of  which  squad  is  ordered  to  begin  the  patrol. 
This  capability  is  made  possible  because  both  squads  can  access  the  maneuver  related 
affordances. 

•  The  act  of  bounding  one  squad  through  the  other  requires  two  affordances  in  the 
same  location.  The  lead  squad  must  access  the  security  formation  affordance  while 
the  following  squad  must  access  a  SquadMove  affordance.  It  is  important  that  indi¬ 
vidual  squads  are  not  able  to  access  both  HTNs.  This  is  accomplished  by  selecting 
appropriate  valid  times  for  TEMPORARY  affordances  or  by  utilizing  ONESHOT  af¬ 
fordances.  This  can  also  be  accomplished  by  manipulating  affordanceValidBoolean 
values  through  the  use  of  an  additional  changeAffordanceValidBoolean  affordance. 

•  Upon  completing  his  patrol,  the  Platoon  Commander  entity  accesses  an  affordance 
that  brings  his  processAffordances  HTN  to  a  goal  state,  and  stops  him  from  attempt¬ 
ing  to  process  affordances.  In  this  example,  it  was  important  that  this  process  not 
take  place  until  several  other  affordances  were  executed.  This  was  accomplished  by 
placing  a  large  time  delay  on  slopProcessAJJordancesHTNA  execution. 

6.4.3  Demonstration  Findings 

Creating  this  initial  demonstration  was  an  important  process  that  drove  further  refinement 
of  the  existing  security  formation  and  affordance  structures.  The  ability  to  access  and  up¬ 
date  stored  HTN  parameters  and  the  flexibility  provided  by  the  “adapter”  HTNs  were  both 
unexpected  benefits  made  possible  through  the  use  of  procedural  affordances.  However, 
with  these  additional  capabilities,  also  come  several  areas  for  caution. 

The  first  area  concerns  behavior  complexity.  Layering  multiple  behaviors  or  HTNs  on  top 
of  one  another  is  a  technique  that  can  increase  reusability.  However,  because  HTNs  are 
slower  than  standard  scripted  behaviors,  simulation  developers  must  ensure  that  each  addi¬ 
tional  level  of  complexity  serves  a  purpose.  In  situations  like  this  when  multiple  HTNs  are 
employed  to  achieve  a  single  behavior,  utilizing  a  clear  naming  convention  is  an  important 
consideration. 

The  next  area  for  caution  concerns  how  procedural  affordances  are  employed.  Scenario 
developers  must  be  aware  that  PERMANENT  affordances  can  cause  problems  if  accessed 
by  too  many  entities,  and  that  ONESHOT  affordances  can  create  issues  if  accessed  by  an 
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Figure  6.7:  Using  Adapter  HTNs  to  Modify  the  Functionality  of  Core  FITNs 


unintended  entity.  All  classifications  of  procedural  affordances  can  display  problems  if  they 
attempt  to  execute  their  associated  HTN  before  a  previous  behavior  has  been  completed. 
While  these  issues  are  potential  pitfalls  to  the  efficient  use  of  affordances  and  HTNs,  the 
affordance  parameters  were  designed  to  let  scenario  developers  tailor  their  behaviors  to 
be  successful  in  any  situation.  Understanding  both  the  capabilities  and  limitations  in  this 
demonstration  promises  to  greatly  ease  future  COMBATXXI  scenario  development. 


6.5  Dynamic  Range  400  Demonstration 

The  next  demonstration  of  the  security  formation  HTN  and  affordance  capabilities  is  pro¬ 
vided  through  a  modification  of  the  R400  scenario  described  in  Chapter  5.  This  scenario 
demonstrates  how  dynamic  behaviors  lower  scenario  creation  time  and  enable  entity  behav¬ 
iors  which  are  more  representative  of  actual  military  tactics.  Specifically,  the  ability  of  the 
security  formation  HTN  to  handle  casualties  is  highlighted.  Finally,  the  scenario  provides 
additional  insights  into  ways  that  these  tools  can  be  improved. 
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6.5.1  Reduction  of  COMBATXXI  Behavior  Mechanisms 

The  process  of  building  the  updated  R400  scenario  primarily  involved  removing  scripted 
aspects  of  the  original  R400  scenario,  and  replacing  them  with  HTNs  and  procedural  af- 
fordances.  A  total  of  two  HTNs  and  six  procedural  affordances  were  utilized  to  create 
the  behaviors  in  the  dynamic  scenario.  The  application  of  these  tools  immediately  re¬ 
sulted  in  a  reduction  of  waypoints,  compound  orders,  and  behaviors.  The  reduction  of 
these  mechanisms  is  shown  in  Figure  6.8.  This  benefit  is  primarily  due  to  the  fact  that 
HTNs  and  affordances  can  be  used  to  control  the  actions  of  multiple  units.  This  aspect  of 
HTNs  and  affordances  could  significantly  lower  the  development  time  required  for  larger 
COMBATXXI  scenarios.  Using  these  tools  to  control  the  actions  of  multiple  units  has 
additional  benefits.  When  scenarios  must  be  modified,  this  design  approach  reduces  the 
number  of  scenario  mechanisms  which  must  be  changed.  This  advantage  directly  affects  a 
scenario’s  reusability. 

6.5.2  Efficient  Behavior  Development  and  Increased  Reusability 

The  next  advantage  of  using  dynamic  behaviors  is  illustrated  through  their  ability  to  cre¬ 
ate  tactically  sound  security  formations.  Figure  6.9,  Figure  6.10,  and  Figure  6.11  compare 
security  formations  conducted  in  both  versions  of  the  R400  scenario.  The  security  forma¬ 
tions  from  the  dynamic  R400  scenario  contain  several  advantages  over  their  scripted  coun¬ 
terparts.  These  advantages  include  properly  oriented  entities,  appropriate  spacing  between 
entities,  and  fewer  COMBATXXI  waypoints. 

It  is  important  to  differentiate  between  behaviors  that  are  technically  feasible  through  the 
use  of  traditional  scripted  methods,  and  behaviors  that  are  not  feasible.  In  regards  to  the 
former  type  of  behavior,  it  is  possible  to  create  scripted  security  formations  that  look  as 
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Figure  6.8:  Comparison  of  Required  Behavior  Mechanisms  for  Scripted  and  Dynamic  Scenarios 


104 


6  6  6 


bP 

T9 


x> 


H 

JO 

AD 

A3 


V 

V  ' 


b 

b 

n 

x> 

■o 

-o 

-O  v 

-O  v 
jO 

b 

P 


6 


d 


V 

V 


d 

V  V  <* 

Cf 

Cr 

o- 

\ 

o- 


a 


p  P  9  9  Q  g 


Q 


a 


Figure  6.9:  Unit  Security  Formation  -  Scripted  (Left)  and  Dynamic  (Right) 


Figure  6.10:  Guardian  Angel  Security  Formation  -  Scripted  (Left)  and  Dynamic  (Right) 


good  as  their  dynamic  counterparts.  However,  this  would  require  a  large  increase  in  the 
number  of  waypoints,  compound  orders,  behaviors,  and  scenario  specific  formations.  Fur¬ 
thermore,  the  work  that  was  invested  in  such  a  process  would  not  be  reusable;  it  would  have 
to  be  repeated  if  the  requirements  for  the  security  formation  changed. 

This  complicated  process  of  creating  security  formations  through  scripted  techniques  is 
why  this  fundamental  military  action  is  left  out  of  many  military  simulations.  The  dynam¬ 
ically  created  security  formations  took  significantly  less  effort  to  create  than  their  scripted 
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Figure  6.11:  Small  Unit  360  Security  Formation  -  Scripted  (Left)  and  Dynamic  (Right) 


counterparts.  Additionally,  these  dynamic  security  formations  can  have  their  geometries 
quickly  adjusted,  can  change  to  accommodate  units  with  different  numbers  of  entities,  and 
can  be  reused  in  different  situations. 


6.5.3  Additional  Capabilities 

Saving  time  and  resources  are  important  benefits  of  utilizing  dynamic  behaviors,  however, 
it  is  even  more  important  to  recognize  the  things  that  dynamic  behaviors  can  accomplish 
but  their  scripted  equivalents  cannot.  Figure  6.12  displays  a  standard  military  security 
formation  that  a  military  unit  is  likely  to  conduct  after  seizing  an  objective.  The  dynamic 
security  formation  behavior  does  a  better  job  of  properly  spacing  and  orienting  each  entity. 
As  previously  noted,  the  scripted  example  could  reproduce  these  results  if  enough  time 
were  invested.  What  the  scripted  formation  cannot  deal  with  are  the  effects  of  battlefield 
casualties.  Figure  6.13  illustrates  what  the  formations  from  Figure  6.12  look  like  when  a 
unit  incurred  casualties  during  an  operation. 

The  scripted  security  formation  in  Figure  6.13  contains  large  gaps  that  were  not  present 
in  the  example  with  no  casualties.  Alternatively,  the  dynamic  security  formation  in  Fig¬ 
ure  6.13  simply  looks  smaller  than  its  no  casualty  counterpart.  The  reason  for  this  discrep¬ 
ancy  is  that  in  the  scripted  example,  each  entity’s  exact  position  has  been  predetermined. 
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When  units  are  attrited  during  the  course  of  an  operation,  the  scripted  security  formation 
behavior  has  no  mechanisms  for  identifying  the  entities  that  became  casualties,  and  read¬ 
justing  the  security  formation.  Gaps  ultimately  appear  in  the  scripted  security  formation 
because  the  scripted  behavior  functions  as  if  the  unit  incurred  no  casualties. 

Dynamic  security  formations  created  with  masterSecurityFormation  do  not  suffer  from 
these  problems  because  entity  positions  are  not  predetermined.  Currently,  the  only  pre¬ 
determined  information  includes  parameters  such  as  formation  location,  orientation,  angle 
to  cover,  and  spacing  between  entities.  When  the  security  formation  behavior  is  activated 
during  the  scenario,  it  analyzes  the  current  personnel  strength  of  the  unit  or  units  tasked 
with  creating  security  formation.  Only  after  this  step  does  the  behavior  assign  locations  to 
individual  entities.  This  dynamic  behavior  approach  is  what  enables  masterSecurityForma¬ 
tion  to  create  security  formations  which  accomplish  the  mission,  regardless  of  whether  or 
not  a  unit  has  incurred  casualties. 

6.5.4  Areas  to  Utilize  Caution 

One  important  purpose  of  dynamic  behaviors  it  to  decrease  scenario  creation  time  through 
the  use  of  reusable  and  scalable  behaviors.  The  dynamic  R400  scenario  provided  an  excel¬ 
lent  example  of  how  composable  behaviors  can  significantly  reduce  scenario  development 
time,  and  can  make  entity  behaviors  more  representative  of  security  formations  conducted 
by  Marines  on  R400.  This  was  possible  because  considerable  effort  was  devoted  to  the  cre¬ 
ation  of  composable  behaviors.  However,  the  creation  of  this  scenario  also  brought  to  light 
several  ways  that  the  affordance  and  HTN  processes  can  be  improved.  As  new  dynamic 
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Figure  6.12:  180  Security  Formation  (No  Casualties)  -  Scripted  (Left)  and  Dynamic  (Right) 
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Figure  6.13:  180  Security  Formation  (With  Casualties)  -  Scripted  (Left)  and  Dynamic  (Right) 


behaviors  are  created,  simulation  developers  should  be  aware  of  several  lessons  learned 
during  the  creation  of  the  dynamic  R400  scenario. 

One  of  the  keys  to  HTN  reusability  is  to  ensure  that  HTN  functionality  is  not  dependent 
upon  specially  created  scripted  behaviors.  An  example  of  such  a  problem  was  found  when 
the  SquadMove  HTN  was  utilized  in  the  dynamic  R400  scenario.  This  HTN  initially  failed 
because  it  was  dependent  upon  a  non-standard  COMBATXXI  unit  formation.  The  problem 
was  corrected  by  importing  the  formation  into  the  R400  scenario;  however,  this  is  an  issue 
that  should  be  avoided  when  creating  composable  behaviors.  It  is  recommended  that  such 
behaviors  utilize  only  standard  COMBATXXI  capabilities,  or  that  unique  HTN  behavior  is 
encapsulated  within  the  HTN  itself. 

Creating  sub-behaviors  which  are  modular  in  nature  is  an  important  step  toward  creating 
composable  behaviors.  HTNs  are  extremely  powerful  tools,  however  a  single  large  HTN 
cannot  be  expected  to  achieve  representative  behavior  in  all  conceivable  situations.  A  bet¬ 
ter  approach  to  achieving  reusability  is  to  create  a  behavior  that  is  constructed  of  numerous 
smaller  HTNs.  If  these  smaller  HTNs  are  created  in  a  modular  fashion,  then  scenario  devel¬ 
opers  can  easily  replace  or  modify  them  so  that  the  overall  behavior  remains  representative 
of  actual  military  operations.  An  example  of  this  action  approach  can  be  seen  through  the 
basicIndividualMove  HTN  that  is  a  part  of  the  security  formation  behavior.  This  behav¬ 
ior  moves  simulation  entities  in  a  very  simple  manner  that  is  not  representative  of  many 
military  situations.  Ground  forces  conducting  a  stealthy  patrol  will  move  differently  than 
forces  conducting  an  assault,  or  forces  moving  through  a  minefield.  To  account  for  this 
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aspect,  basicIndividualMove  was  created  separately  from  the  rest  of  the  security  behavior. 
Should  a  scenario  developer  desire  additional  realism  in  entity  movement,  this  HTN  can  be 
replaced  with  one  or  more  HTNs  that  achieve  the  desired  goals. 

One  of  the  major  benefits  of  the  security  formation  behavior  is  its  ability  to  function  with 
units  that  have  incurred  casualties.  Because  future  HTNs  must  be  able  to  do  the  same 
thing,  it  is  important  to  understand  some  of  the  challenges  that  were  overcome  to  achieve 
this  capability.  When  the  security  formation  behavior  was  first  tested  in  a  scenario  where 
casualties  occurred,  it  failed  in  cases  where  the  casualties  included  unit  leaders.  The  reason 
for  this  was  that  COMBATXXI  often  did  not  designate  a  new  unit  leader,  and  that  many 
of  the  security  behavior  HTNs  would  only  function  if  they  were  assigned  to  a  unit  leader. 
This  is  the  first  situation  in  which  simulation  developers  must  exercise  caution.  The  next 
situation  in  which  the  security  formation  behavior  initially  failed  was  when  a  command 
level  unit  was  completely  destroyed.  The  security  formation  behavior  was  designed  to 
replicate  the  orders  process  of  actual  military  units  in  which  a  command  unit  receives  orders 
from  its  higher  headquarters,  processes  those  orders,  and  then  passes  modified  orders  down 
to  its  subordinate  forces.  In  real  life,  if  that  command  unit  were  destroyed,  then  subordinate 
unit  members  reconstitute  the  command  unit.  This  action  does  not  happen  automatically 
in  COMBATXXI,  and  is  the  reason  why  the  security  formation  behavior  initially  failed. 
When  devising  future  HTNs,  simulation  developers  must  create  behaviors  that  are  robust 
enough  to  handle  such  limitations. 

6.5.5  Range  400  Conclusion 

The  previously  mentioned  issues  are  ones  that  developers  should  be  aware  of  when  con¬ 
structing  new  scenarios.  Truly  composable  behaviors  are  rarely  easy  to  develop;  however, 
the  advantages  they  provide  are  tremendous.  Within  the  dynamic  R400  scenario,  a  greater 
amount  of  time  was  required  to  properly  remove  older  scripted  behaviors,  than  was  required 
to  apply  the  newer  dynamic  behaviors.  Should  this  scenario  continue  to  be  developed,  the 
reusable  and  scalable  aspects  of  these  behaviors  will  drastically  ease  the  creation  process  of 
future  R400  iterations,  and  add  additional  realism  to  the  tactical  actions  being  conducted. 
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CHAPTER  7: 

Recommendations  and  Conclusions 


Dr.  Andrew  Ilachinksi’s  book  Artificial  War  details  his  work  at  the  Center  for  Naval  Anal¬ 
ysis  (CNA)  when  MCCDC  Commanding  General,  Lieutenant  General  Van  Riper  opened 
the  “Offices  of  New  Sciences  to  delve  into  the  possibility  of  employing  complexity  theory 
in  support  of  the  command’s  mission”  [1,  p.  viii] .  This  work  produced  two  simulations, 
Irreducible  Semi-Autonomous  Adaptive  Combat  (ISAAC)  and  Enhanced  ISAAC  Neural 
Simulation  Tool  (EINSTein),  which  ushered  in  a  new  era  of  simulation  technology.  For 
the  first  time,  simulations  offered  the  potential  for  analysts  to  move  beyond  the  typical 
Cold  War  era  question  of,  “which  computer-generated  army  won,”  and  focus  on  the  more 
insightful  question  of,  “why  did  one  of  the  computer-generated  armies  win?” 

According  to  Ilachinski,  models  usually  fell  into  one  of  two  categories,  those  “highly  realis¬ 
tic  models  that  [provided]  little  insight  into  basic  processes. . .  [and  those]  ultra-minimalist 
models  that  [stripped]  away  all  but  the  simplest  dynamical  variables  and  [left]  out  the  most 
interesting  real  behavior”  [1,  p.  14].  The  work  accomplished  by  Ilachinski  produced  sim¬ 
ulations  that  found  a  balance  between  these  two  extremes.  One  of  the  reasons  ISAAC 
and  EINSTein  represented  revolutionary  systems  was  that  they  provided  the  opportunity 
to  model  detailed  system  behaviors  while  retaining  the  ability  to  analyze  overall  system 
processes. 

Within  the  United  States  Army  and  Marine  Corps,  the  COMBATXXI  simulation  has  the 
potential  to  become  the  present  day  embodiment  of  the  ideas  produced  by  Ilachinski.  It  is 
a  system  which  models  the  most  detailed  elements  of  combat,  including  weapons  system 
performance,  environmental  effects,  and  human  behavior.  However,  the  dynamic  behavior 
potential  of  this  system  has  only  seen  minimal  use.  One  aspect  of  military  operations  that 
is  missing  from  most  combat  simulations,  including  COMBATXXI,  is  an  effort  to  model 
dynamic  tactical  behaviors. 

In  relation  to  many  simulations,  COMBATXXI  provides  a  detailed  representation  of 
weapons,  unit  organizations,  and  basic  tactics.  Unfortunately,  many  realistic  human  be¬ 
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haviors  and  military  tactics,  techniques,  and  procedures  (TTPs)  must  either  be  scripted  by 
scenario  designers,  or  modeled  implicitly.  In  older  Cold  War  era  simulations,  this  method¬ 
ology  provided  suitable  results  to  the  questions  being  asked.  As  technology  has  advanced 
and  simulations  have  gained  the  ability  to  represent  more  detailed  actions,  a  need  emerged 
to  correctly  represent  the  behaviors  of  smaller  units.  An  additional  factor  which  impacts 
these  considerations  is  the  changing  role  of  the  individual  in  modern  warfare.  Due  to 
the  evolution  of  technology  and  tactics,  individual  soldiers  and  Marines  currently  have  a 
greater  impact  on  warfare  than  at  any  previous  time.  If  a  high-resolution  simulation  such 
as  COMBATXXI  is  expected  to  provide  valuable  insights  into  modern  warfare,  each  of  the 
above  factors  must  be  considered.  These  issues  guided  the  research  conducted  in  support 
of  this  thesis. 


7.1  Recommended  Improvements  to  Thesis  Products 

The  security  formation  behavior  and  the  affordance  mechanism  produced  in  support  of  this 
thesis  aided  the  COMBATXXI  scenario  construction  process  in  the  following  ways: 

Representation  &  Efficiency:  enabled  scenario  entities  to  display  increasingly  realistic 
tactical  actions,  and  lowered  the  time  required  for  scenario  developers  to  create  these 
tactical  actions 

Composability:  demonstrated  how  several  modular  HTNs  could  work  together  to  produce 
a  single  doctrinally  correct  tactical  behavior 

Reusability  &  Scalability:  created  a  composable  behavior  with  high  template  based  reuse 
properities  that  could  function  well  in  different  scenarios  or  with  different  sized  units 
Parameters:  identified  parameters  necessary  for  the  effective  utilization  of  procedural  af- 
fordances  and  dynamic  security  formation  behaviors 
Creation:  identified  future  military  behaviors  to  model  dynamically;  identified  doctrinal 
military  sources  that  should  be  used  to  guide  the  development  of  these  behaviors 

The  products  produced  within  this  thesis  were  intended  to  ease  the  introduction  of  dynamic 
behaviors  into  COMBATXXI.6  If  this  goal  is  to  become  a  reality,  the  following  improve¬ 
ments  to  the  thesis  products  are  recommended. 

Additional  information  concerning  thesis  products  can  be  obtained  from  the  NPS  Modeling,  Virtual 
Environments,  and  Simulation  (MOVES)  Institute  at  the  following  address:  simulation@nps.edu. 
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7.1.1  Security  Formation  Areas  for  Improvement 

The  security  formation  behavior  offers  scenario  developers  many  capabilities,  however,  it 
needs  further  improvement  in  order  to  address  some  of  the  tactical  deficiencies  cited  in 
Chapter  5.  Figure  7.1  illustrates  additional  capabilities  that  would  increase  the  security 
formation  behavior’s  utility.  The  first  major  area  for  improvement  involves  placing  entities 
in  portions  of  the  security  formation  that  best  suit  their  capabilities.  In  real  life  this  process 
begins  when  military  commanders  analyze  subordinate  unit  capabilities,  enemy  threats, 
and  terrain  characteristics. 

Within  COMBATXXI,  analyzing  subordinate  unit  capabilities  should  be  conducted  in  con¬ 
junction  with  master  Security  Formation  and  unitSecurity  Formation.  These  HTNs  were  de¬ 
signed  to  be  integrated  with  future  AI  mechanisms  capable  of  analyzing  a  subordinate 
unit’s  capabilities  and  assigning  suitable  security  formation  positions  to  that  subordinate 
unit.  Figure  7.2  provides  an  example  of  what  a  subordinate  unit  analysis  could  look  like 
for  a  Marine  Infantry  Squad  (13  Marines)  which  has  been  reinforced  by  an  Assault  Team 
(2  Marines).  If  such  a  capability  were  combined  with  terrain  and  enemy  threat  informa¬ 
tion,  algorithms  within  unitSecurityFormation  could  be  used  to  place  the  Assault  Team  in 
the  security  positions  most  conducive  to  the  employment  of  the  team’s  anti-armor  weapon 
system.  Additional  methods  of  employment  for  this  capability  include  placing  the  most 
effective  combat  units  in  more  dangerous  locations,  and  placing  headquarters  units  in  posi¬ 
tions  where  they  can  accomplish  their  command  and  control  responsibilities.  It  is  important 
to  recognize  that  in  these  examples,  the  forces  being  analyzed  and  adjusted  are  units  which 
are  composed  of  multiple  entities.  Eventually,  the  positions  of  individual  entities  must  also 
be  determined.  Such  a  task  can  be  accomplished  in  conjunction  with  simpleUnitSecurity- 
Formation  and  should  use  an  algorithm  designed  to  assess  individual  entity  capabilities. 

The  second  major  area  for  improvement  involves  the  refinement  of  individual  security  po¬ 
sitions.  Currently,  masterSecurityFormation  is  the  HTN  responsible  for  identifying  the 
location  of  each  individual  security  position.  This  real  life  equivalent  of  this  action  occurs 
when  a  unit  leader  conducts  a  reconnaissance  of  a  battle  position  that  his  unit  will  occupy 
in  the  near  future.  During  this  reconnaissance,  the  leader  designates  approximate  locations 
of  fighting  positions.  In  real  life,  initial  fighting  position  locations  will  often  be  adjusted  in 
order  to  maximize  a  unit’s  capabilities.  Within  the  current  security  formation  behavior,  the 
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Figure  7.1:  Proposed  Hierarchy  of  Security  Formation  Mechanisms 


initial  security  formation  locations  are  exactly  where  entities  will  eventually  be  located.  To 
improve  upon  this,  functionality  must  be  developed  to  allow  the  modification  of  security 
positions.  Such  algorithms  would  help  avoid  problems  in  which  entities  have  their  field 
of  view  blocked,  or  situations  in  which  entities  fail  to  take  advantage  of  nearby  cover  and 
concealment. 

All  of  these  recommendations  involve  making  the  action  within  the  security  formation 
behavior  more  representative  of  what  happens  in  real  life.  While  accomplishing  these  rec¬ 
ommendations  would  increase  the  behavior’s  utility,  the  behavior  would  still  be  heavily  de¬ 
pendent  upon  formation  parameters  created  by  the  scenario  developer.  Examples  of  these 
parameters  include  formation  orientation,  dispersion  among  entities,  and  angle  of  respon¬ 
sibility.  The  way  to  advance  the  security  formation  behavior  to  the  next  level  is  to  create 
a  higher-level  HTN  that  is  able  to  develop  these  parameters  itself.  This  HTN  would  have 
important  ramifications  if  it  was  capable  of  direct  reuse,  and  scenario  developers  could  trust 
the  behavior  to  create  reasonably  appropriate  security  formations.  This  step  would  enable 
an  encapsulated  security  formation  behavior  to  be  utilized  within  other  higher  level  HTNs. 
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Figure  7.2:  Analysis  of  Subunit  Capabilities 


Such  a  system  has  the  potential  to  significantly  decrease  scenario  developer  workload. 
However,  producing  a  behavior  that  can  accomplish  these  tasks  presents  many  challenges. 
Friendly  unit  capabilities,  terrain  characteristics,  and  enemy  threat  are  all  key  pieces  of  in¬ 
formation  that  a  commander  considers  when  deciding  how  to  array  his  subordinate  forces. 
Each  of  these  areas  must  be  further  developed  if  the  behavior  is  to  achieve  its  full  potential. 
First,  the  framework  for  analyzing  friendly  unit  capabilities  discussed  in  this  work  should 
be  expanded.  Second,  the  COMBATXXI  Pathfinder  program  should  be  researched  to  see  if 
it  can  provide  the  necessary  terrain  analysis  capabilities.  Finally,  functionality  must  be  cre¬ 
ated  to  assess  enemy  threats.  Unfortunately  this  is  a  more  complicated  topic  since  enemy 
threat  information  can  come  from  many  sources,  and  may  or  may  not  be  accurate.  One  way 
of  simplifying  this  problem  is  by  using  informational  affordances  to  convey  enemy  threat 
information. 


7.1.2  Affordance  Areas  For  Improvement 

The  current  affordance  structure  provides  scenario  developers  a  great  deal  of  capabilities 
in  regard  to  procedural  affordances.  However,  there  exist  some  areas  in  which  scenario 
developers  must  exercise  caution,  and  several  ways  the  affordance  functionality  should  be 
improved. 

•  Adding  an  HTN  to  an  entity’s  goal  stack  does  not  guarantee  whether  or  not  an  entity 
will  execute  a  specific  action.  Execution  is  ultimately  determined  by  code  within  the 
HTN  itself.  This  aspect  means  that  scenario  developers  must  take  care  to  ensure  that 
the  wrong  entity  does  not  gain  access  to  ONESHOT  affordances. 

•  When  entities  that  are  not  unit  leaders  move  as  part  of  a  formation,  they  lose  their 
ability  to  sense  affordances.  This  is  because  of  the  way  that  COMBATXXI  executes 
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formation  moves. 

•  Numerous  tools  are  available  for  ensuring  that  the  right  entities  gain  access  to  affor- 
dances.  These  tools  could  be  supplemented  by  the  ability  to  change  an  affordance’s 
access  roster  in  the  middle  of  a  scenario. 

•  The  ability  for  entities  to  create  affordances  within  a  scenario  could  be  a  powerful 
tool  for  producing  dynamic  behaviors.  This  improvement  would  face  many  of  the 
same  challenges  involved  with  changing  an  affordance’s  access  roster  in  the  middle 
of  a  scenario. 

•  While  procedural  affordances  can  be  used  in  a  number  of  ways,  limitations  will  even¬ 
tually  be  reached  in  their  utility.  The  ultimate  goal  should  be  the  development  of  in¬ 
formational  affordances  similar  to  the  Killzone  2  “annotations”  that  were  described 
in  Chapter  3. 


7.2  Expanding  HTN  Usage  in  COMBATXXI 

The  products  of  this  thesis  shed  light  on  some  of  the  capabilities  that  dynamic  behaviors 
offer  military  simulations.  Further  improvements  to  these  tools  can  benefit  COMBATXXI 
scenarios.  Additional  scenario  construction  tools  would  also  prove  beneficial.  One  of  the 
problems  with  utilizing  Python  scripts  and  HTNs  is  that  they  are  prone  to  syntax  errors. 
Improving  the  graphical  user  interface  (GUI)  by  adding  error  checking  capabilities  would 
greatly  benefit  scenario  designers.  However,  the  best  way  to  solidify  HTNs  usage  within 
COMBATXXI  is  to  use  these  existing  tools  as  inspiration  for  the  creation  of  additional 
dynamic  behavior  mechanisms. 

7.2.1  Development  of  Additional  Behaviors 

This  thesis  began  with  the  intent  of  creating  an  HTN  that  was  capable  of  conducting  a  basic 
ground  attack.  Unfortunately,  creating  a  dynamic  attack  behavior  was  a  more  complicated 
process  than  originally  anticipated.  Because  of  this,  the  decision  was  made  to  focus  on 
producing  a  composable  version  of  a  subordinate  behavior  that  could  later  be  integrated 
into  an  attack  behavior.  The  security  formation  behavior  was  chosen  for  this  purpose.  It 
accomplished  the  thesis  purpose,  which  was  to  demonstrate  that  doctrinal  tactical  behav¬ 
iors  can  be  modeled  using  HTNs,  that  HTNs  can  provide  additional  realism  within  the 
COMBATXXI  scenarios,  and  that  HTNs  can  create  reusable  and  scalable  behaviors  which 
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are  useful  in  a  variety  of  situations. 

Future  work  should  focus  on  creating  additional  behaviors  that  a  military  unit  exhibits 
when  attacking  a  defensive  enemy  position.  In  general,  these  actions  include  those  which 
begin  at  the  unit’s  assembly  area,  continue  through  actions  on  the  objective,  and  end  upon 
consolidation  when  the  unit  has  finished  preparations  for  potential  enemy  counterattacks. 
Examples  of  such  tactical  behaviors  include  the  following: 

1 .  Movement  to  Contact 

2.  Support  by  Fire 

3.  Fire  and  Maneuver 

4.  Fire  and  Movement 

5.  Consolidate 

Producing  dynamic  behaviors  of  these  actions  would  play  an  important  role  in  establishing 
a  realistic  and  composable  attack  behavior.  This  is  a  fundamental  military  action  which 
must  be  modeled  if  HTN  usage  is  to  be  expanded.  The  creation  of  an  attack  behavior  would 
provide  many  insights  into  modeling  automated  military  tactics  and  could  ultimately  result 
in  the  establishment  of  a  behavior  library  that  would  revolutionize  the  manner  in  which 
COMBATXXI  scenarios  are  created. 

7.2.2  Continued  Development  of  a  Dynamic  Range  400  Scenario 

As  additional  dynamic  behaviors  are  produced,  the  R400  scenario  should  be  utilized  to 
demonstrate  behavior  capabilities.  The  actual  R400  is  designed  to  provide  training  for 
all  units  within  USMC  infantry  battalions.  This  fact  gives  a  simulated  version  of  R400 
an  opportunity  to  showcase  a  wide  range  of  tactical  behaviors.  Because  a  mature  R400 
evaluation  system  already  exists,  this  scenario  also  offers  the  opportunity  to  run  new  be¬ 
haviors  through  a  structured  V&V  process.  R400  training  standards  are  described  in  detail 
by  the  TTECG  produced  R400  Handbook  [47].  Should  the  R400  scenario  continue  to  be 
utilized,  scenario  developers  should  reference  the  example  scheme  of  maneuver  depicted 
in  Appendix  B. 

An  additional  benefit  of  continuing  to  use  the  R400  scenario  stems  from  the  fact  that  this  is 
one  of  the  Marine  Corps’  premier  live  fire  training  facilities.  This  range  is  well  known  to  in- 
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fantry  Marines;  creating  automated  behaviors  capable  of  executing  tactics  representative  of 
those  seen  during  actual  R400  runs  would  gamer  much  attention.  Creating  higher  level  be¬ 
haviors  capable  of  representing  the  decision  making  process  of  unit  leaders  on  R400  would 
be  an  even  greater  accomplishment,  and  could  ultimately  take  COMBATXXI  capabilities 
to  a  new  level. 

7.3  Steps  Toward  a  Mission  Planning  Capability 

From  the  first  days  of  military  boot  camps,  recruits  and  officer  candidates  are  taught  to 
perform  basic  actions  as  a  tactical  unit.  Over  time,  military  members  leam  TTPs  that 
dictate  what  general  actions  to  perform  in  almost  any  situation.  In  order  to  ensure  that  the 
proper  actions  can  be  performed  in  the  chaos  of  combat,  these  skills  are  practiced  repeatedly 
until  they  become  second  nature.  Conducted  concurrently  with  this  training  are  a  variety 
of  decision  making  exercises  in  which  military  leaders  analyze  their  current  situation  and 
decide  upon  a  course  of  action  for  their  unit.  The  unit  leader  accomplishes  this  decision 
making  process  by  selecting  a  known  technique  for  use,  by  deciding  to  modify  a  previously 
learned  technique,  or  by  devising  a  completely  new  course  of  action.  This  training  exists 
because  the  proper  execution  of  tactical  behaviors  increases  a  unit’s  ability  to  effectively 
engage  enemy  forces. 

Creating  a  simulation  capable  of  executing  a  similar  decision  making  process  would  rep¬ 
resent  a  revolutionary  level  of  technology.  The  current  limitations  of  AI  make  this  a  long 
term  goal.  Making  strides  toward  this  goal  within  the  COMBATXXI  simulation  will  re¬ 
quire  many  advances.  Capabilities  such  as  the  Pathfinder  program  need  to  be  integrated 
with  dynamic  behavior  mechanisms,  while  aspects  such  as  the  unit  command  structure 
must  be  updated  to  better  reflect  actual  military  organizations.  These  are  just  some  of  the 
steps  required  for  the  achievement  of  a  mission  planning  capability;  however,  the  substan¬ 
tial  impact  such  a  system  could  have  on  the  military  planning  process  would  make  this 
effort  worthwhile.  The  dynamic  behavior  techniques  established  within  this  thesis  are  a 
step  in  that  direction. 
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APPENDIX  A: 

Technical  Discussion  of  Affordances 


The  gaming  industry  has  successfully  utilized  the  affordance  concept  as  a  mechanism  to 
control  the  behavior  of  NPCs.  This  appendix  describes  how  an  affordance  capability  was 
developed  for  COMBATXXI.  From  2007  to  2008,  basic  affordance  components  and  an  ini¬ 
tial  implementation  were  developed  by  Dr.  Ron  Noel  at  TRADOC  Analysis  Center  -  White 
Sands  Missile  Range  (TRAC-WSMR)  [48].  In  this  work  he  demonstrated  the  feasibility  of 
using  affordances  in  combat  models  -  specifically  COMBATXXI.  The  affordance  concept 
received  additional  attention  during  one  of  Dr.  Imre  Balogh’s  classes.  The  implementation 
presented  in  this  thesis  builds  on  the  concepts  initially  developed  by  Dr.  Noel,  and  refined 
by  members  of  Dr.  Balogh’s  class. 

A.l  Functionality 

The  COMBATXXI  affordance  system  functions  in  a  manner  similar  to  the  simple  embed¬ 
ded  behavior  technique  described  in  Chapter  2.  At  present  time,  COMBATXXI  affordances 
are  similar  to  those  embedded  behaviors  that  provide  scripts  for  an  entity  to  execute.  How¬ 
ever  in  this  system,  HTNs  are  utilized  instead  of  scripts.  Within  the  scope  of  this  thesis,  this 
technique  is  referred  to  as  a  “procedural  affordance.”  Chapter  2  also  describes  a  technique 
in  which  behavioral  “hints”  can  be  embedded  into  terrain;  the  game  Killzone  2  uses  a  re¬ 
lated  technique  in  conjunction  with  its  AI  to  produce  advanced  dynamic  behaviors.  Though 
not  currently  possible  in  COMBATXXI,  the  ability  to  develop  such  capabilities  was  part 
of  the  affordance  structure’s  design.  Within  the  scope  of  this  thesis,  this  technique  is  re¬ 
ferred  to  as  an  “informational  affordance.”  The  following  files  were  constructed  to  give 
COMBATXXI  affordances  their  current  level  of  functionality: 

•  affordanceUtilities  (Java  Library) 

•  affordancelnitialization  (Python  Script) 

•  processAffordances  (HTN) 

The  first  file,  affordanceUtilities,  is  a  library  that  contains  the  bulk  of  the  methods  related 
to  affordance  functionality.  Important  features  include  methods  for  establishing  affordance 
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waypoints,  manipulating  affordance  parameters,  and  determining  if  an  entity  can  access  an 
affordance.  Because  this  work  focused  on  procedural  affordances,  several  methods  exist  to 
expand  HTN  functionality.  The  final  purpose  of  this  file  is  to  store  affordance  related  infor¬ 
mation.  When  the  library  is  first  used,  it  instantiates  several  maps  that  organize  information 
such  as  affordance  parameters,  HTN  parameters,  and  affordance-entity  access  rosters.  As 
of  the  date  of  this  thesis,  this  file  resides  in  the  COMBATXXI  Monterey  Extensions  pack¬ 
age. 

The  second  file,  affordance  Initialization,  is  a  script  that  instantiates  the  affordances  for  a 
scenario.  The  affordance  Initialization  file  should  be  imported  into  a  scenario’s  jump_start 
script.  This  script  works  closely  with  the  other  affordance  files,  and  with  SITS.  The  first 
step  to  instantiate  an  affordance  involves  using  SITS  to  create  waypoints  to  designate  the 
locations  of  affordances.  Next,  the  scenario  designer  will  input  a  list  of  affordance  pa¬ 
rameters  using  the  affordanceUtilities.createNewAffordance()  method.  This  will  result  in 
the  creation  of  a  COMBATXXI  affordance  waypoint.  If  the  affordances  are  procedural  in 
nature,  this  is  also  the  time  to  store  HTN  parameters.  The  final  function  of  affordancelni- 
tialization  is  to  add  the  processAffordances  HTN  to  the  goal  stacks  of  entities  that  need  to 
access  affordances. 

The  third  file,  processAffordances  is  an  HTN  that  enables  COMBATXXI  entities  to  access 
and  utilize  affordances.  Figure  A.l  depicts  the  structure  of  this  HTN.  So  as  not  to  inter¬ 
fere  with  other  HTNs  that  entities  execute,  processAffordances  is  not  added  to  the  entity’s 
primary  goal  stack.  This  HTN  has  two  main  parts.  The  first  part  is  an  initialization  pro¬ 
cess  that  runs  once  for  each  entity  utilizing  the  HTN.  By  accessing  information  from  the 
affordance-entity  access  roster  in  affordanceUtilities,  this  section  of  code  informs  entities 
what  affordances  they  should  be  aware  of  as  they  navigate  a  COMBATXXI  scenario.  Once 
the  initialization  steps  have  been  accomplished,  the  HTN  “idles”  until  the  entity  comes 
within  range  of  an  affordance  of  interest.  When  this  happens,  a  replan  triggers  the  second 
part  of  the  HTN.  The  purpose  of  this  action  is  to  verify  that  the  entity  has  access  to  the 
affordance.  Once  access  has  been  granted,  processAffordances  retrieves  the  HTN  that  is 
linked  to  the  affordance,  and  adds  it  to  the  entity’s  primary  goal  stack.  This  last  step  is  sim¬ 
plified  because  all  affordances  are  currently  procedural  in  nature.  As  the  COMBATXXI 
affordance  capability  is  refined,  additional  actions  will  become  possible.  For  example, 
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functionality  has  been  built  into  the  process  that  will  allow  entities  to  utilize  informational 
affordances  integral  to  more  advanced  dynamic  behaviors. 


A.2  Features 

COMBATXXI  affordances  are  most  comparable  to  the  gaming  industry’s  legacy  technique 
of  defining  NPC  actions  through  the  use  of  embedded  scripts.  However,  the  current  affor- 
dance  methodology  contains  features  not  available  in  most  video  games.  These  features 
can  be  generally  categorized  as  mechanisms  for  allowing  an  entity  to  access  affordances, 
and  as  capabilities  created  by  the  combination  of  affordances  and  HTNs. 

An  entity’s  ability  to  access  affordances  is  designated  within  the  affordancelnitializa- 
tion.createNewAffordance()  method.  At  this  point,  access  can  be  authorized  for  individual 
entities,  all  entities  within  a  designated  unit,  entities  of  a  specified  SideType,  or  all  enti¬ 
ties  within  the  scenario.  The  second  feature  allows  scenario  developers  to  designate  the 
range  at  which  an  affordance  can  be  detected.  This  enables  entities  to  access  co-located 
affordances  in  a  desired  order.  Next,  the  ability  to  classify  affordances  as  PERMANENT, 
TEMPORARY,  or  ONESHOT  further  refines  the  ability  to  designate  when  affordances  can 
or  cannot  be  accessed.  A  PERMANENT  affordance  can  be  accessed  repeatedly  by  any 
number  of  entities.  A  TEMPORARY  affordance  can  only  be  accessed  within  a  specified 
time  window.  A  ONESHOT  affordance  can  only  be  accessed  a  single  time.  For  TEM¬ 
PORARY  and  ONESHOT  affordances  that  have  exceeded  their  life  expectancy,  access  is 
denied  to  future  entities  by  the  automatic  adjustment  of  the  affordance’s  “affordance Valid- 
Boolean.”  This  automatic  adjustment  can  be  deliberately  executed  through  the  use  of  the 
affordcinceUtilities  method  that  changes  affordanceValidBoolean  values.  This  capability 
enables  scenario  designers  to  activate,  deactivate,  or  reactivate  affordances  at  any  point  of 
their  choosing. 

The  next  set  of  features  was  derived  from  the  unanticipated  benefit  of  combining  affor¬ 
dances  and  HTNs.  Many  of  these  capabilities  were  made  possible  because  of  the  versatile 
nature  of  HTNs.  The  first  benefit  involves  allowing  scenario  developers  to  set  a  time  delay 
until  a  procedural  affordance’s  HTN  is  executed.  This  is  accomplished  in  the  ajfordanceU- 
tilities.createNewAjfordance()  method  and  allows  co-located  procedural  affordances  to  be 
executed  in  sequence.  The  second  feature  of  the  affordance-HTN  combination  enables 
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\ _ ,  processAffordances 

9  initlnfo 

addReplanTriggers 

haveEntityListenForAffordances 

endlnit 

9  events 

9  isGoalTrackerEvent 
9  isStopAffordanceTree 

stopAftordanceTree 
9  modelEvents 

9  isAtAControlMeasure 

9  isAffordance 

9  isEntityHaveAccessToAffordance 
executeAffordance 
stopListeningForAffordance 
(V)  noWorkLeft 


Figure  A.l:  Depiction  of  the  processAffordances  HTN  Structure 


affordances  to  trigger  actions  at  other  places  in  the  scenario.  An  example  of  this  is  the  mas- 
terSecurity Formation  HTN  described  in  Chapter  6,  in  which  the  HTNs  parameters  include 
the  unit  or  units  to  execute  the  action.  This  technique  is  applicable  to  military  operations 
because  of  their  event-driven  nature.  This  means  that  specific  movements  or  actions  of  one 
unit  can  be  used  to  initiate  actions  of  other  units.  Creating  such  a  behavioral  relationship 
could  be  facilitated  through  the  use  of  affordances  and  HTNs  similar  in  nature  to  masterSe- 
curity Formation.  However,  care  must  be  used  when  employing  this  mechanism  to  ensure 
that  communication  modeling  is  represented  in  accordance  with  the  modeling  assumptions. 
The  third  benefit  of  procedural  affordances  concerns  the  HTN  parameters.  When  proce¬ 
dural  affordances  are  created,  HTN  parameters  are  stored  within  an  affordcinceUtilities 
HashMap  called  “htnParameterContainer.”  This  important  step  enables  HTN  parameters 
to  be  accessed  and  updated  in  the  middle  of  a  scenario.  Uses  for  this  feature  with  regard 
to  masterSecurityFormation  include  updating  the  participating  units  or  the  geometry  of 
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the  security  formation.  The  final  feature  of  using  the  processAffordcinces  HTN  to  process 
affordances  is  that  this  feature  can  be  turned  off.  In  a  large  scenario,  having  numerous  en¬ 
tities  attempting  to  process  affordances  can  become  a  computationally  expensive  process. 
In  order  to  prevent  unnecessary  calculations,  an  entity’s  processAffordcinces  HTN  can  be 
brought  to  a  goal  state  when  a  scenario  developer  determines  that  there  is  no  additional 
need  for  that  entity  to  access  affordances. 
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APPENDIX  B: 

Range  400  Example  Attack 


The  following  presentation  illustrates  an  example  of  how  a  reinforced  Marine  infantry  com¬ 
pany  conducted  a  R400  evolution  at  MCAGCC,  29  Palms,  CA.  If  R400  is  utilized  in  future 
studies,  this  example  will  give  scenario  designers  a  frame  of  reference  for  the  overall  tactics 
executed  on  R400.  This  example  was  derived  from  source  [49]. 
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1.  SST  REPORT 

2.  GUNS  UP  MORT  AND  HMG  ON  PRIORITY  TGTS 
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Q®.  ASSESS  EFFECTS 

i  12.  COMPANY  MOVES  THROUGH  BREACH 
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17.  81’S  SHIFT  FIRE 

18.  3rd  PLT  ASSAULTS  SW 

19.  1st  PLT  CEASES  FIRE 

20.  MMG SHIFT 


4TH,  PROVIDE  SECURITY  FOR  CASEVAC,  SUPPORT  ENGINEERS  FOR 
CACHE  SWEEP. 
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31.  MMG  SHIFT  CEASE 


32.  4TH  PLT  SBF  SHIFT 


129 


38.  ENG  SET  UP  FOR  CACHE  SWEEP 


31 .  ENG  SET  UP  FOR  CACHE  SWEEP 
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APPENDIX  C: 
Scenario  Initialization  Files 


The  purpose  of  the  scripts  in  this  appendix  is  to  initialize  HTNs  and  affordances  within  the 
R400  and  urban  patrol  scenarios. 


Range  400  jump_start.py 


This  script  adds  HTNs  to  the  goal  stacks  of  entities  in  the  R400  scenario. 


from  HTN  import  UtilityFuncsExp 

from  mtry  .  cxxi  .  model .  HierarchicalTaskNetwork  import  GoalContainer 
from  cxxi  .  model .  objects  .  holders  import  CMHolder 
from  java,  util  import  ArrayList 
import  math 


#  print  a  debug  message 
print  " " 

print  info  .  getMyAssignedName  :  JUMP  START!  " 
print  " " 


#  run  the  affordancelnitialization  script  to  instantiate  all  affordances  within  the  scenario 
initialize  AffordancesB  oolean  =  True 
if  initializeAffordancesBoolean  : 

from  HTN  import  r400Affordance!nitialization 


GoalContainer.  init AllEntities  () 


#  CONTROL  MEASURE  NAMES  OF  INTEREST 

FUPCenterPosCM  =  CMHolder .  retrieveControlMeasureByName  ( "  FUPCenterPos  " ) 


#  PLATOON  COMMANDER  NAME  (DOES  NOT  ACTIVELY  PARTICIPATE  IN  SCENARIO) 

#  "MarPltCOl " 

#  MAIN  UNIT  NAMES 

#  "PltlSqdl  " 

#  "  Pit  1  Sqd2  " 

#  "MGSqdl " 

#  GUARDIAN  ANGEL  UNIT  NAMES 

#  "PltlSqdl  " 

activateHTN  =  True 
if  activateHTN  : 
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arrayListOfUnitNames  =  ArrayListQ 
arrayListOfUnitNames  .  add ("PltlSqdl  ") 
arrayListOfUnitNames  .  add  ( "  Pit  1  Sqd2  " ) 
arrayListOfUnitNames  .  add  ( "MGSqdl " ) 

UtilityFuncsExp  .  addGoal( 

" MarPltCOl "  , 

1.0, 

"HTN/ Trees  /  masterSecurityFormation  .xml"  , 

["RECURSIVE",  arrayListOfUnitNames,  FUPCenterPosCM  ,  22.0,  (0 . 0)  *math  .  pi  ,  (2.0)*math  .  pi  ,  "CENTER",  "CONVEX",  "True"], 
None) 


arrayListOfUnitNames  =  ArrayListQ 
arrayListOfUnitNames  .  add  ("PltlSqdl  ") 

UtilityFuncsExp  .  addGoal( 

"MarPltCOl "  , 

2000.0, 

"HTN/ Trees  /  masterSecurityFormation  .xml"  , 

["RECURSIVE",  arrayListOfUnitNames,  FUPCenterPosCM,  45.0,  ( 1 .2)  *math  .  pi  ,  ( 1 . 7 )  *math  .  pi  ,  "CENTER",  "CONVEX",  "True"], 
None) 


#  print  a  debug  message 
print  " " 

print  info  .  getMyAssignedName  ()  , "  :  JUMP  START  COMPLETE!" 
print  " " 


This  script  initializes  affordances  within  the  R400  scenario. 


from  mtry  .  cxxi  .  model .  HierarchicalTaskNetwork  import  GoalContainer 

from  cxxi  .  model .  objects  .  holders  import  CMHolder 

from  java,  util  import  ArrayList 

from  cxxi  .  model .  behavior  import  OrderUtilities 

import  UtilityFuncs 

from  HTN  import  UtilityFuncsExp 

from  java,  util  import  Set 

from  mtry  .  cxxi  .  model .  affordances  import  affordanceUtilities 
import  math 


#  print  a  debug  message 
print  " " 

print  "start  affordancelnitialization" 
print  " " 


#  retrieve  control  measures  from  scenario  file  and  assign  to  local  variables 

ala  =  CMHolder .  retrieveControlMeasureByName  ("  affordance  1  a  " ) 
a2a  =  CMHolder .  retrieveControlMeasureByName  ("  affordance2a  " ) 
a2b  =  CMHolder .  retrieveControlMeasureByName  ("  affordance2b  " ) 
a2c  =  CMHolder .  retrieveControlMeasureByName  ("  affordance2c  " ) 
a3a  =  CMHolder .  retrieveControlMeasureByName  ("  affordance3 a  " ) 
a4a  =  CMHolder .  retrieveControlMeasureByName  ("  affordance4a  " ) 

mgHillSecPosCenterWP  =  CMHolder  ,retrieveControlMeasureByName("mgHillSecPosCenter") 
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################################################################################### 
#  5  STEP  PROCESS  TO  SET  UP  SCENARIO  AFFORDANCES 
################################################################################### 


#  STEP  1  -  SITS 

################################################################################### 

#  Place  (normal)  waypoints  in  SITS  scenario  file  that  correspond  to  desired  affordance  locations 

#  Give  these  waypoints  a  name  that  is  in  accordance  with  your  affordance  naming  convention  (ie  —  affordance  1  a ) 

#  If  using  HTNs  that  require  locations  as  parameters  ,  place  create  these  waypoints  as  well 

#  If  desired  ,  the  waypoints  marking  the  affordance  location  can  double  as  an  HTN  parameter 


#  STEP  2  -  WRITE  CODE  TO  INITIALIZE  AFFORDANCES 
################################################################################### 

# 

#  THREE  PART  PROCESS 

#  A:  create  the  affordance  using  affordanceUtilities  .  createNew Affordance  ()  method 

#  B:  create  a  list  of  parameters  to  be  used  with  an  HTN  (if  required) 

#  C:  store  the  list  of  HTN  parameters  using  affordanceUtilities  .  updateHtnParameterContainer  ()  method  (if  required) 

# 

#  EXPLANATION  OF  PARAMETERS  USED  WHEN  CREATING  A  NEW  AFFORDANCE 

#  affordanceUtilities  .  createNewAffordance  (  wayPointNameFromSits  where  affordance  is  to  be  located, 

#  list  of  entity  names  who  can  access  affordance  (can  be  empty) 

#  list  of  unit  names  whose  entities  can  access  affordance  (can  be  empty) 

#  affordanceValidBoolean  (True  or  False), 

#  affordanceType  (PERMANENT,  ONESHOT,  OR  TEMPORARY)  , 

#  quickAccessClassifier  (NONE,  ALL,  BLUE,  RED,  GREEN,  etc...), 

#  time  in  seconds  at  which  a  TEMPORARY  affordance  becomes  valid  , 

#  time  in  seconds  at  which  a  TEMPORARY  affordance  becomes  invalid  , 

#  delay  in  seconds  until  a  PROCEDURE  affordance  adds  an  HTN  to  an  entity’s  goal  stack 

#  rangelnMeters  at  which  an  entity  can  sense  that  an  affordance  exists  , 

#  type  of  affordance  (PROCEDURE  or  INFORMATION) 

#  data  (for  a  PROCEDURE  affordance  this  will  usually  be  the  location  of  an  HTN) 


#  affordancela  —  uses  RECURSIVE  version  of  masterSecurityFormation  ;  all  units  that  are  part  of  "MGSqdl"  participate  in 
the  formation 

affordanceUtilities  .  createNewAffordance  ("  affordance  1  a "  ,  []  ,  []  ,  "True",  "ONESHOT",  "BLUE",  "0",  "0",  "60",  "5",  " 
PROCEDURE"  ,  "HTN/  Trees /  masterSecurityFormation  .  xml" ) 

recursionDescriptor  =  "RECURSIVE" 
unitNamesArrayList  =  ArrayListQ 
unitNamesArrayList  .  add(  "MGSqdl" ) 
formationLocation  =  mgHillSecPosCenterWP 
arcBetweenLocations  =  10.0 
formationOrientation  =  (0.0)  *math  .  pi 
angleToCover  =  (2 . 0)  *math  .  pi 
formationCenterDescriptor  =  "CENTER" 
convexConcaveString  =  "CONVEX" 
uselsCommanderBoolean  =  "False" 

parameterList  =  [recursionDescriptor,  unitNamesArrayList,  formationLocation,  arcBetweenLocations,  formationOrientation, 
angleToCover,  formationCenterDescriptor,  convexConcaveString,  uselsCommanderBoolean] 

affordanceUtilities  .  updateHtnParameterContainer  ("affordancela"  ,  parameterList) 


#  affordance2a  —  traditional  use  of  SquadMove  coupled  with  an  affordance 
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affordanceUtilities  .  createNewAffordance  ( "  affordance2a "  ,  []  ,  []  ,  "True",  "PERMANENT",  "BLUE",  "0",  "0",  "60",  "5", 
PROCEDURE"  ,  "HTN/  Trees  /SquadMove.  xml") 

parameterList  =  [a2a,  a3a] 

affordanceUtilities  .  updateHtnParameterContainer("affordance2a"  ,  parameterList) 


#  affordance2b  —  a  modification  of  SquadMove;  this  enables  one  unit  to  trigger  actions  by  another  unit 

affordanceUtilities  .  createNewAffordance  ("  affordance2b  "  ,  []  ,  []  ,  "True",  "ONESHOT"  ,  "BLUE",  "0",  "0",  "60",  "5", 
PROCEDURE"  ,  "HTN/ Trees  /  SquadMove_MoveDesignatedUnits  .  xml"  ) 

unitNameToExecuteList  =  ArrayListQ 
unitNameToExecuteList .  add  ( "  Pit  1  Sqd2  " ) 
unitNameToExecuteList .  add(  "PltlSqd2Tml " ) 
unitNameToExecuteList .  add(  "PltlSqd2Tm2" ) 
unitNameToExecuteList .  add(  "PltlSqd2Tm3  " ) 
parameterList  =  [unitNameToExecuteList,  ala,  a4a] 

affordanceUtilities  .  updateHtnParameterContainer("affordance2b"  ,  parameterList) 


#  affordance2c  —  a  modification  of  SquadMove;  this  enables  one  unit  to  trigger  actions  by  another  unit 

affordanceUtilities  .  createNewAffordance  ("  affordance2c "  ,  []  ,  []  ,  "True",  "ONESHOT",  "BLUE",  "0",  "0",  "300",  "5", 
PROCEDURE"  ,  "HTN/  Trees  / SquadMove_MoveDesignatedUnits  .  xml"  ) 

unitNameToExecuteList  =  ArrayListQ 
unitNameToExecuteList  .  add  ( "MGSqdl  "  ) 
unitNameToExecuteList .  add  ( "MGSqdlTml " ) 
unitNameToExecuteList .  add  ( "MGSqdlTm2" ) 

parameterList  =  [unitNameToExecuteList,  mgHillSecPosCenterWP  ,  a4a] 
affordanceUtilities  .  updateHtnParameterContainer("affordance2c"  ,  parameterList) 


#  affordance3a  —  uses  NONRECURSIVE  version  of  masterSecurity Formation  ;  only  designated  units  (no  subordinates) 
participate  in  formation 

affordanceUtilities  .  createNewAffordance  ("  affordance3a  "  ,  []  ,  [ "  Pit  1  Sqd  1  "  ]  ,  "True",  "ONESHOT",  "NONE",  "0",  "0",  "90",  "5" 
,  "PROCEDURE",  "HTN/  Trees  /  masterSecurity  Formation  .  xml" ) 

recursionDescriptor  =  "NONRECURSIVE" 
unitNamesArrayList  =  ArrayListQ 
unitNamesArrayList  .  add ( "  Pit  1  Sqd  1  " ) 
unitNamesArrayList  .  add(  "PltlSqdlTml " ) 
unitNamesArrayList  .  add(  "PltlSqdlTm2" ) 
unitNamesArrayList  .  add  ( "  Pit  1  SqdlTm3  " ) 
formationLocation  =  a3a 
arcBetweenLocations  =  5.0 
formationOrientation  =  (0. 1 )  *math  .  pi 
angleToCover  =  (0.6)  *math  .  pi 
formationCenterDescriptor  =  "FLOT" 
convexConcaveString  =  "CONVEX" 
uselsCommanderBoolean  =  "True" 


134 


155 

156 

157 

158 

159 

160 

161 

162 

163 

164 

165 

166 

167 

168 

169 

170 

171 

172 

173 

174 

175 

176 

177 

178 

179 

180 

181 

182 

183 

184 

185 

186 

187 

188 

189 

190 

191 

192 

193 

194 

195 

196 

197 

198 

199 

200 

201 

202 

203 

204 

205 

206 

207 

208 

209 

210 

211 

212 

213 

214 

215 

216 


parameterList  =  [  recursionDescriptor  ,  unitNamesArrayList  ,  formationLocation  ,  arcBetweenLocations  ,  formationOrientation  , 
angleToCover  ,  formationCenterDescriptor  ,  convexConcaveString  ,  uselsCommanderBoolean ] 

affordanceUtilities  .  updateHtnParameterContainer("affordance3a"  ,  parameterList) 


#  affordance4a  —  uses  a  modification  of  masterSecurityFormation ;  as  units  arrive  at  affordance  ,  they  are  integrated  into 
formation 

affordanceUtilities  .  createNewAffordance  ("  affordance4a "  ,  []  ,  []  ,  "True",  "PERMANENT",  "BLUE",  "0",  "0",  "60",  "5",  " 
PROCEDURE"  ,  "HTN/  Trees  /  sec  uri  t  y  Forma  tion_by  Phase  Affordance  Mod  .  xml"  ) 

affordanceName  =  "  affordance4a  " 
recursionDescriptor  =  "NONRECURSIVE" 
unitNamesArrayList  =  ArrayListQ 

#unitNamesArrayList  .  add  ("  someUnitName ")  #  this  value  is  left  empty  for  this  HTN 

formationLocation  =  a4a 

arcBetweenLocations  =  5.0 

formationOrientation  =  (0. 1 )  *math  .  pi 

angleToCover  =  (0.75)*math  .  pi 

formationCenterDescriptor  =  "FLOT" 

convexConcaveString  =  "CONVEX" 

uselsCommanderBoolean  =  "True" 

parameterList  =  [affordanceName,  recursionDescriptor,  unitNamesArrayList,  formationLocation,  arcBetweenLocations, 
formationOrientation,  angleToCover,  formationCenterDescriptor,  convexConcaveString,  uselsCommanderBoolean] 

affordanceUtilities  .  updateHtnParameterContainer("affordance4a"  ,  parameterList) 


#  STEP  3  -  INVERTED  GATEKEEPER 

################################################################################# 

#  creates  an  invertedGateKeeper  which  is  used  in  the  HTN  to  tell  entities  what  affordance s  to  listen  for 

#  this  method  must  be  run  after  the  affordances  have  been  initialized 

#  this  method  must  be  run  before  process  Affordances  .  xml  is  added  to  each  entity’s  goal  stack 
affordanceUtilities  .  createlnvertedGateKeeperQ 


#  STEP  4  -  TELL  ENTITIES  TO  LISTEN  FOR  AFFORDANCES 
################################################################################# 

#  enable  designated  entities  to  listen  for  affordances 

#  must  be  done  for  all  entities  that  need  to  access  affordances 

#  must  be  done  after  the  invertedGate Keeper  has  been  created 

#  NOTE:  this  affordance  is  added  to  an  entity’s  "  affordanceStack "  and  not  its  primary  goal  stack 


listOfEntityNames  =  []  #  left  empty  for  the  purpose  of  this  demonstration 
for  entityName  in  listOfEntityNames: 

UtilityFuncsExp  .  addSpecificGoal  ( 
entityName  , 

1.0, 

"HTN/ Trees  /  process  Affordances  .xml"  , 

"affordanceStack"  , 

[]  - 

None) 
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listOfUnitNames  =  ["PltlSqdl"  ,  ”  PltlSqdlTml"  ,  "PltlSqdlTm2"  ,  "PltlSqdlTm3  "  ,  "MGSqdl"  ,  "MGSqdlTml”  ,  "MGSqdlTm2"  , 
Pit  1  Sqd2  "  ,  "PltlSqd2Tml "  ,  "PltlSqd2Tm2"  ,  " Pit  1  Sqd2Tm3  "  ] 
for  unitName  in  listOfUnitNames: 

UtilityFuncsExp  .  addS pecificGoalToUnit  ( 
unitName  , 

1.0, 

"HTN/ Trees  /  process  Affordances  .xml"  , 

"affordanceStack"  , 

[]  - 

None) 


#  STEP  5  —  import  this  script  into  the  scenario’s  jump  start  file 
################################################################################### 


#  print  a  debug  message 
print  " " 

print  "  af f or d an c e I n i t i a  1  i za t i o n  complete" 
print  " " 


This  script  adds  HTNs  to  the  goal  stacks  of  entities  in  the  urban  patrol  scenario. 


from  mtry  .  cxxi  .  model .  HierarchicalTaskNetwork  import  GoalContainer 

from  cxxi  .  model .  objects  .  holders  import  CMHolder 

from  java,  util  import  ArrayList 

from  cxxi  .  model .  behavior  import  OrderUtilities 

import  UtilityFuncs 

from  HTN  import  UtilityFuncsExp 

from  java,  util  import  Set 

from  mtry  .  cxxi  .  model .  affordances  import  affordanceUtilities 
import  math 


#  print  a  debug  message 
print  " " 

print  info  .  getMyAssignedName  ()  , "  :  JUMP  START!  " 
print  " " 


############################################################################################## 

#  CAUTION:  if  the  scenario  is  changed  to  maneuver  units  down  streets  with  numerous  buildings 

#  the  scenario  will  likely  break.  This  is  because  SquadMove .  xml  will  activate  its  MovelnBoundingOverwatch .  xml 

#  option.  masterSecurityFormation  .  xml  does  not  currently  work  with  this  HTN.  The  reason  for  this 

#  is  because  of  the  way  that  MovelnBoundingOverwatch .  xml  adjusts  a  unit’s  task  organization 
############################################################################################### 


#  run  the  affordancelnitialization  script  to  instantiate  all  affordances  within  the  scenario 
initializeAffordancesBoolean  =  True 
if  initializeAffordancesBoolean: 

from  HTN  import  urbanPatrol Affordancelnitialization 
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#  assign  local  variables 


#rl_s  =  CMHolder.  retrieveControlMeasureByName  ("  roadl_start  ") 
#rl_e  =  CMHolder.  retrieveControlMeasureByName  ("  roadl_end  ") 
r2_s  =  CMHolder .  retrieveControlMeasureByName  ("  road2_start " ) 
r2_e  =  CMHolder .  retrieveControlMeasureByName  ("  road2_end  " ) 
r3_t  =  CMHolder .  retrieveControlMeasureByName  ("  road3_top  " ) 
r3_b  =  CMHolder .  retrieveControlMeasureByName  ("  road3_bottom  " ) 

namePlatoonCommander  =  "DEFAULT_TEAM/B_1MAN_969" 


#  assign  HTNs  to  Platoon  Commander  in  order  to  start  the  scenario 
demoPlatoonCommander  =  True 
goalPath  =  "HTN/ Trees /SquadMove  .  xml" 


if  demoPlatoonCommander: 

UtilityFuncsExp  .  addGoal( 
namePlatoonCommander  , 
1.0, 

goalPath  , 

[r2_s  ,  r2_e  ]  , 

None) 

UtilityFuncsExp  .  addGoal( 
namePlatoonCommander  , 
70.0, 
goalPath  , 

[r2_e  ,  r 3 _t ]  , 

None) 

UtilityFuncsExp  .  addGoal( 
namePlatoonCommander  , 
125.0, 
goalPath  , 

[  r 3 _t  ,  r3_b  ]  , 

None) 


#  print  a  debug  message 
print  " " 

print  info  .  getMyAssignedName  ()  , "  :  JUMP  START  COMPLETE!" 
print  " " 


C.4  urbanPatrolAffordancelnitialization.py 

This  script  initializes  affordances  within  the  urban  patrol  scenario. 

from  mtry  .  cxxi  .  model .  HierarchicalTaskNetwork  import  GoalContainer 

from  cxxi  .  model .  objects  .  holders  import  CMHolder 

from  java,  util  import  ArrayList 

from  cxxi  .  model .  behavior  import  OrderUtilities 

import  UtilityFuncs 

from  HTN  import  UtilityFuncsExp 

from  java,  util  import  Set 

from  mtry  .  cxxi  .  model .  affordances  import  affordanceUtilities 
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import  math 


#  print  a  debug  message 
print  " " 

print  "start  affordancelnitialization" 
print  " " 


#  assign  local  variables 

#rl_s  =  CMHolder.  retrieveControlMeasureByName  ("  roadl_start  ") 
#rl_e  =  CMHolder .  retrieveControlMeasureByName  ("  roadl_end  ") 
r2_s  =  CMHolder .  retrieveControlMeasureByName  ("  road2_start " ) 
r2_e  =  CMHolder .  retrieveControlMeasureByName  ("  road2_end  " ) 
r3_t  =  CMHolder .  retrieveControlMeasureByName  ("  road3_top  " ) 
r3_b  =  CMHolder .  retrieveControlMeasureByName  ("  road3_bottom  " ) 
d_s  =  CMHolder .  retrieveControlMeasureByName  ("  demo_start " ) 


platoonCommander  =  "DEFAULT_TEAM/B_1MAN_969" 
commanderSquadl  =  "  DEFAULT_TEAM  /  B_  1 M  AN_948 " 
commanderSquad2  =  "  DEFAULT_TEAM  /  B_  1  MAN_959 " 

nameSquadl  =  "INF_PLATOON_l /INF_SQUAD_1" 
nameSquad2  =  "INF_PLATOON_l  /  INF_SQU  AD_2 " 


####################################################################################### 

#  if  desired  ,  the  lead  squad  can  be  changed  to  nameSquad2 

#  the  scenario  was  designed  so  that  it  would  work  regardless  of  which  squad  moved  first 
leadSquadForDemonstration  =  nameSquadl 

####################################################################################### 


################################################################################### 
#  5  STEP  PROCESS  TO  SET  UP  SCENARIO  AFFORDANCES 
################################################################################### 


#  STEP  1  -  SITS 

################################################################################### 

#  Place  (normal)  waypoints  in  SITS  scenario  file  that  correspond  to  desired  affordance  locations 

#  Give  these  waypoints  a  name  that  is  in  accordance  with  your  affordance  naming  convention  (ie  —  affordance  1  a ) 

#  If  using  HTNs  that  require  locations  as  parameters  ,  place  create  these  waypoints  as  well 

#  If  desired  ,  the  waypoints  marking  the  affordance  location  can  double  as  an  HTN  parameter 


#  STEP  2  -  WRITE  CODE  TO  INITIALIZE  AFFORDANCES 
################################################################################### 

# 

#  THREE  PART  PROCESS 

#  A:  create  the  affordance  using  affordanceUtilities  .  createNewAffordance  ()  method 

#  B:  create  a  list  of  parameters  to  be  used  with  an  HTN  (if  required) 

#  C:  store  the  list  of  HTN  parameters  using  affordanceUtilities  .  updateHtnParameterContainer  ()  method  (if  required) 

# 

#  EXPLANATION  OF  PARAMETERS  USED  WHEN  CREATING  A  NEW  AFFORDANCE 
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#  affordanceUtilities  .  createNewAffordance  (  wayPointNameFromSits  where  affordance  is  to  be  located, 


# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 


list  of  entity  names  who  can  access  affordance  (can  be  empty) 

list  of  unit  names  whose  entities  can  access  affordance  (can  be  empty) 

affordanceValidBoolean  (True  or  False), 

affordanceType  (PERMANENT,  ONESHOT,  OR  TEMPORARY)  , 

quickAccessClassifier  (NONE,  ALL,  BLUE,  RED,  GREEN,  etc...), 

time  in  seconds  at  which  a  TEMPORARY  affordance  becomes  valid  , 

time  in  seconds  at  which  a  TEMPORARY  affordance  becomes  invalid  , 

delay  in  seconds  until  a  PROCEDURE  affordance  adds  an  HTN  to  an  entity’s  goal  stack 
rangelnMeters  at  which  an  entity  can  sense  that  an  affordance  exists  , 
type  of  affordance  (PROCEDURE  or  INFORMATION) 

data  (for  a  PROCEDURE  affordance  this  will  usually  be  the  location  of  an  HTN) 


#  affordanceOa 


affordanceUtilities  .  createNewAffordance  ("  affordanceOa  "  ,  [commanderSquadl  ,  commanderSquad2  ]  ,  []  ,  "True",  "ONESHOT",  "NONE 
",  "0",  "0",  "0.1",  "10",  "PROCEDURE",  "HTN/ Trees  /  changeAffordance  ValidBoolean  .  xml " ) 

affordancesToChangeList  =  ArrayListQ 
afford ancesToChangeList  .  add ("affordancela") 
affordancesToChangeList  .  add ("affordancelb") 
affordancesToChangeList  .  add  ("affordance2b") 
affordancesToChangeList  .  add ("affordance2c") 
affordancesToChangeList  .  add  ("affordance2d") 
affordancesToChangeList  .  add(  "affordance3a") 
affordancesToChangeList  .  add ("affordance3b") 
affordancesToChangeList  .  add ("affordance3c") 
affordancesToChangeList  .  add ("affordance4a") 
affordancesToChangeList  .  add  ("affordance4b") 
parameterList  =  ["SWITCH”,  affordancesToChangeList] 

affordanceUtilities  .  updateHtnParameterContainer("  affordanceOa"  ,  parameterList) 


#  affordancela 


affordanceUtilities  .  createNewAffordance  ("  affordance  1  a  "  ,  [commanderSquadl,  commanderSquad2  ]  ,  []  ,  "False",  "TEMPORARY",  " 
NONE",  "0",  "350",  "50",  "30",  "PROCEDURE",  "HTN/ Trees  /  SquadMove_OtherUnitsInArrayList .  xml" ) 

unitNameToExecuteList  =  ArrayListQ 
unitNameToExecuteList .  add(nameSquadl ) 
unitNameToExecuteList .  add  ( nameSquad2 ) 
parameterList  =  [unitNameToExecuteList,  r2_s  ,  r2_e  ] 

affordanceUtilities  .  updateHtnParameterContainer("affordancela"  ,  parameterList) 


#  affordancelb 


affordanceUtilities  .  createNewAffordance  ("  affordance  1  b  "  ,  []  ,  [nameSquadl  ,  nameSquad2],  "False",  "ONESHOT",  "NONE",  "0"  , 
0",  "1",  "10",  "PROCEDURE",  "HTN/  Trees  /  security  Formation_by  ProcessingUnit  .  xml" ) 

recursionDescriptor  =  "NONRECURSIVE" 
unitNamesArrayList  =  ArrayListQ 

#unitNames ArrayList .  add ( someUnitName )  #  this  field  left  empty  for  this  HTN 

formationLocation  =  r2_s 

arcBetweenLocations  =  5.0 

formationOrientation  =  ( 1 ,05)*math  .  pi 

angleToCover  =  (0.55)*math  .  pi 
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formationCenterDescriptor  =  "FLOT" 
convexConcaveString  =  "CONCAVE" 
uselsCommanderBoolean  =  "True" 

parameterList  =  [  recursionDescriptor  ,  unitNamesArrayList  ,  formationLocation  ,  arcBetweenLocations  ,  formationOrientation  , 
angleToCover  ,  formationCenterDescriptor,  convexConcaveString,  uselsCommanderBoolean] 

affordanceUtilities  .  updateHtnParameterContainer("affordancelb"  ,  parameterList) 


#  affordance2a 

affordanceUtilities  .  createNewAffordance  ("  affordance2a  "  ,  [commanderSquadl  ,  commanderSquad2  ]  ,  []  ,  "False",  "ONESHOT"  ,  " 
NONE",  "0",  "0",  "1",  "15",  "PROCEDURE",  "HTN/ Trees /SquadMove  .  xml " ) 

parameterList  =  [r2_e  ,  r 3 _ t  ] 

affordanceUtilities  .  updateHtnParameterContainer("affordance2a"  ,  parameterList) 


#  affordance2b 

affordanceUtilities  .  createNewAffordance  ("  affordance2b "  ,  []  ,  []  ,  "False",  "ONESHOT",  "BLUE",  "0",  "0",  "1",  "50",  " 
PROCEDURE"  ,  "HTN/  Trees/securityFormation_byProcessingUnit.  xml"  ) 

recursionDescriptor  =  "NONRECURSIVE" 
unitNamesArrayList  =  ArrayListQ 
formationLocation  =  r2_e 
arcBetweenLocations  =  5.0 
formationOrientation  =  ( 1 . 9 )  *math  .  pi 
angleToCover  =  (0 .05 )  *math  .  pi 
formationCenterDescriptor  =  "FLOT" 
convexConcaveString  =  "CONVEX" 
uselsCommanderBoolean  =  "True" 

parameterList  =  [recursionDescriptor,  unitNamesArrayList,  formationLocation,  arcBetweenLocations,  formationOrientation, 
angleToCover,  formationCenterDescriptor,  convexConcaveString,  uselsCommanderBoolean] 

affordanceUtilities  .  updateHtnParameterContainer("affordance2b"  ,  parameterList) 


#  affordance2c 

affordanceUtilities  .  createNewAffordance  ("  affordance2c "  ,  []  ,  []  ,  "False",  "ONESHOT",  "BLUE",  "0",  "0",  "50",  "15", 
PROCEDURE"  ,  "HTN/  Trees  /  SquadMove_OtherU  nit  sin  Array  List  .  xml" ) 

unitNameToExecuteList  =  ArrayListQ 
unitNameToExecuteList .  add(nameSquadl ) 
unitNameToExecuteList .  add  ( nameSquad2 ) 
parameterList  =  [unitNameToExecuteList,  r2_s  ,  r2_e  ] 

affordanceUtilities  .  updateHtnParameterContainer("affordance2c"  ,  parameterList) 


#  affordance2d 

affordanceUtilities  .  createNewAffordance  ("  affordance2d "  ,  []  ,  []  ,  "False",  "ONESHOT",  "ALL",  "0",  "0",  "25",  "15", 
PROCEDURE"  ,  "HTN/  Trees /changeAffordanceValidBoolean.  xml" ) 
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affordancesToChangeList  =  ArrayListQ 
afford ancesToChangeList  .  add ("affordance2a") 
parameterList  =  ["SWITCH”,  affordancesToChangeList] 

affordanceUtilities  .  updateHtnParameterContainer("affordance2d"  ,  parameterList) 


#  affordance3a 

affordanceUtilities  .  createNewAffordance  ("  affordance3a  "  ,  [commanderSquadl  ,  commanderSquad2  ]  ,  []  ,  "False",  "TEMPORARY",  " 
NONE",  "560",  "99999",  "1",  "25",  "PROCEDURE",  "HTN/ Trees /SquadMove .  xml" ) 

parameterList  =  [r3_t,  r3_b] 

affordanceUtilities  .  updateHtnParameterContainer("affordance3a"  ,  parameterList) 


#  affordance3b 

affordanceUtilities  .  createNewAffordance  ("  affordance3b "  ,  []  ,  []  ,  "False",  "ONESHOT"  ,  "BLUE",  "0",  "0",  "1",  "5",  " 
PROCEDURE"  ,  "HTN/  Trees/securityFormation_byProcessingUnit.  xml"  ) 

recursionDescriptor  =  "NONRECURSIVE" 
unitNamesArrayList  =  ArrayListQ 
formationLocation  =  r3_t 
arcBetweenLocations  =  5.0 
formationOrientation  =  ( 1 . 6)  *math  .  pi 
angleToCover  =  (1 .35)*math  .  pi 
formationCenterDescriptor  =  "CENTER" 
convexConcaveString  =  "CONVEX" 
uselsCommanderBoolean  =  "True" 

parameterList  =  [recursionDescriptor,  unitNamesArrayList,  formationLocation,  arcBetweenLocations,  formationOrientation, 
angleToCover,  formationCenterDescriptor,  convexConcaveString,  uselsCommanderBoolean] 

affordanceUtilities  .  updateHtnParameterContainer("affordance3b"  ,  parameterList) 


#  affordance3c 

affordanceUtilities  .  createNewAffordance  ("  affordance3c "  ,  []  ,  []  ,  "False",  "ONESHOT",  "BLUE",  "0",  "0",  "50",  "15", 
PROCEDURE"  ,  "HTN/  Trees  /  SquadMove_OtherU  nit  sin  Array  List  .  xml" ) 

unitNameToExecuteList  =  ArrayListQ 
unitNameToExecuteList .  add(nameSquadl ) 
unitNameToExecuteList .  add  ( nameSquad2 ) 
parameterList  =  [unitNameToExecuteList,  r2_e  ,  r3_t] 

affordanceUtilities  .  updateHtnParameterContainer("affordance3c"  ,  parameterList) 


#  affordance4a 

affordanceUtilities  .  createNewAffordance  ("  affordance4a "  ,  []  ,  []  ,  "False",  "PERMANENT",  "BLUE",  "0",  "0",  "30",  "5", 
PROCEDURE"  ,  "HTN/  Trees  /  securityFormation_byPhaseAffordanceMod  .  xml "  ) 

affordanceName  =  "  affordance4a  " 
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recursionDescriptor  =  "NONRECURSIVE" 
unitNamesArrayList  =  ArrayListQ 
formationLocation  =  r3_b 
arcBetweenLocations  =  5.0 
formationOrientation  =  ( 1 .0)*math  .  pi 
angleToCover  =  (2 . 0)  *math  .  pi 
formationCenterDescriptor  =  "CENTER" 
convexConcaveString  =  "CONVEX" 
uselsCommanderBoolean  =  "True" 

parameterList  =  [  affordanceName  ,  recursionDescriptor,  unitNamesArrayList,  formationLocation,  arcBetweenLocations, 
formationOrientation,  angleToCover,  formationCenterDescriptor,  convexConcaveString,  uselsCommanderBoolean] 

affordanceUtilities  .  updateHtnParameterContainer("affordance4a"  ,  parameterList) 


#  affordance4b 

affordanceUtilities  .  createNewAffordance  ("  affordance4b  "  ,  []  ,  []  ,  "False",  "ONESHOT"  ,  "BLUE",  "0",  "0",  "50",  "10", 
PROCEDURE"  ,  "HTN/  Trees  /  SquadMove_OtherU  nit  sin  Array  List  .  xml" ) 

unitNameToExecuteList  =  ArrayListQ 
unitNameToExecuteList .  add(nameSquadl ) 
unitNameToExecuteList .  add  ( nameSquad2 ) 
parameterList  =  [unitNameToExecuteList,  r  3  _t  ,  r3_b  ] 

affordanceUtilities  .  updateHtnParameterContainer("affordance4b"  ,  parameterList) 


#  affordance4c 

affordanceUtilities  .  createNewAffordance  ("  affordance4c  "  ,  [  platoonCommander  ]  ,  []  ,  "True",  "ONESHOT",  "NONE",  "0",  "0",  " 
120",  "10",  "PROCEDURE",  "HTN/ Trees  /  SquadMove_MoveDesignatedUnits  .  xml " ) 

unitNameToExecuteList  =  ArrayListQ 

unitNameToExecuteList .  add (leadSquadForDemonstration) 
parameterList  =  [unitNameToExecuteList,  d_s  ,  r2_s] 

affordanceUtilities  .  updateHtnParameterContainer("affordance4c"  ,  parameterList) 


#  affordance4d 

affordanceUtilities  .  createNewAffordance  ("  affordance4d "  ,  [platoonCommander],  []  ,  "True",  "PERMANENT",  "NONE",  "0",  "0",  " 
90",  "10",  "PROCEDURE",  "HTN/ Trees  /  stopProcessAffordancesHTN  .  xml" ) 

parameterList  =  []  #  no  parameters  needed  for  this  HTN 

affordanceUtilities  .  updateHtnParameterContainer("affordance4d"  ,  parameterList) 


#  affordance4e 

affordanceUtilities  .  createNewAffordance  ("  affordance4e "  ,  [platoonCommander].  []  ,  "True",  "ONESHOT",  "NONE",  "0",  "0",  "1 
,  "5",  "PROCEDURE",  "HTN/ Trees  /  masterSecurityFormation  .  xml" ) 
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recursionDescriptor  =  "  NONRECURSIVE" 
unitNamesArrayList  =  ArrayList  () 
uni  tNames  Array  List  .  add  ( nameSquadl ) 
unitNamesArrayList  .  add  ( nameSquad2) 
formationLocation  =  d_s 
arcBetweenLocations  =  4.0 
formationOrientation  =  ( 1 .0)*math  .  pi 
angleToCover  =  (2 . 0)  *math  .  pi 
formationCenterDescriptor  =  "CENTER" 
convexConcaveString  =  "CONVEX" 
uselsCommanderBoolean  =  "True" 

parameterList  =  [recursionDescriptor,  unitNamesArrayList,  formationLocation,  arcBetweenLocations,  formationOrientation, 
angleToCover,  formationCenterDescriptor,  convexConcaveString,  uselsCommanderBoolean] 

affordanceUtilities  .  updateHtnParameterContainer("affordance4e"  ,  parameterList) 


#  affordance4f 

aff  ordanceU  t  ili  t  i  e  s  .  createNewAffordance  ( "  affordance4f "  ,  [  platoonCommander  ]  ,  []  ,  "True",  "ONESHOT"  ,  "NONE",  "0",  "0",  "60 
",  "5",  "PROCEDURE",  "HTN/  Trees  /  removeUnitFromAffSecForm  .  xml" ) 

wpNamelnSits  =  "  affordance4e  " 
listOfUnitNamesToRemove  =  ArrayList  () 

listOfUnitNamesToRemove  .  add  ( leads  quad  For  Demonstration  ) 
controlMeasureToMoveTo  =  d_s 
newFormationParameterBoolean  =  "True" 
newArcBetweenLocations  =  10.0 

parameterList  =  [wpNamelnSits,  listOfUnitNamesToRemove,  controlMeasureToMoveTo,  newFormationParameterBoolean, 
newArcBetweenLocations] 

affordanceUtilities  .  updateHtnParameterContainer("affordance4f"  ,  parameterList) 


#  STEP  3  -  INVERTED  GATEKEEPER 

################################################################################# 

#  creates  an  invertedGateKeeper  which  is  used  in  the  HTN  to  tell  entities  what  affordances  to  listen  for 

#  this  method  must  be  run  after  the  affordances  have  been  initialized 

#  this  method  must  be  run  before  process  Affordances  .  xml  is  added  to  each  entity’s  goal  stack 
affordanceUtilities  .  createlnvertedGateKeeperQ 


#  STEP  4  -  TELL  ENTITIES  TO  LISTEN  FOR  AFFORDANCES 
################################################################################# 

#  enable  designated  entities  to  listen  for  affordances 

#  must  be  done  for  all  entities  that  need  to  access  affordances 

#  must  be  done  after  the  in vertedGate Keeper  has  been  created 

#  NOTE:  this  affordance  is  added  to  an  entity’s  "  affordanceStack "  and  not  its  primary  goal  stack 

HstOfEntityNames  =  [commanderSquadl  ,  commanderSquad2  ,  platoonCommander] 
for  entityName  in  HstOfEntityNames: 

UtilityFuncsExp  .  addSpecificGoal  ( 
entityName  , 

1.0, 
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"HTN/  Trees  /  processAffordances  .  xml"  , 
" affordanceStack "  , 

[]  , 

None) 


listOfUnitNames  =  [] 

for  unitName  in  listOfUnitNames: 

UtilityFuncsExp  .  addS pecificGoalToUnit  ( 
unitName  , 

1.0, 

"HTN/  Trees /  processAffordances  .  xml"  , 
"affordanceStack"  , 

[]  , 

None) 


#  STEP  5  —  import  this  script  into  the  scenario’s  jump  start  file 
################################################################################### 


#  print  a  debug  message 
print  " " 

print  "  affordancelnitialization  complete" 
print  " " 
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APPENDIX  D: 
Affordance  Files 


The  following  files  are  responsible  for  creating  the  affordance  functionality  within  COMBATXXI. 


D.l  affordanceUtilities.java 

This  script  contains  functions  that  are  utilized  by  the  other  affordance  files. 

package  mtry  .  cxxi .  model .  affordances  ; 

import  cxxi  .  model .  knowledge  .  group  .  OperationalGroup  ; 

import  cxxi  .  model .  knowledge  .  group  .  holders  .  NewUnitHolder  ; 

import  cxxi  .  model .  objects  .  entity  .  Entity  ; 

import  cxxi .  support  .  UniquelDFactory  ; 

import  cxxi  .  model .  objects  .  features  .  CMWayPoint ; 

import  cxxi  .  model .  objects  .  features  .  ControlMeasure  ; 

import  cxxi  .  model .  objects  .  holders  .  CMHolder ; 

import  cxxi  .  model .  physics  .  geometry  .  Location  ; 

import  cxxi .  support  .  types  .  SideType  ; 

import  cxxi .  support  .  types  .  WayPointType  ; 

import  java  .  util  .  ArrayList  ; 

import  java  .  util  .  HashMap  ; 

import  java  .  util  .  List  ; 

import  java  .  util  .  Set ; 

import  simkit  .  Schedule  ; 

public  class  affordanceUtilities  { 

//  these  variables  are  "instantiated"  when  the  first  "affordanceUtilities"  method  is  called  by  a  python  script 
//  these  maps  are  used  to  store  information  which  is  necessary  to  make  the  affordances  work 

public  static  HashMap<String  ,  Object>  workingTagContainer=  new  HashMapoQ;  //  holds  the  "data"  that  corresponds  to 
an  affordance 

public  static  HashMap<String  ,  List>  workingGateKeeper  =  new  HashMapoQ;  //  holds  a  HstOfEntitiesWithAccess  list 
for  each  affordance  uniquelD 

public  static  HashMap<S tring  ,  HashMap>  workingTag AttributeContainer  =  new  HashMap oO ;  //  holds  attributes  that 
affect  how  each  affordance  functions 

public  static  HashMap<S tring  ,  List>  workinglnvertedGateKeeper  =  new  HashMapoQ;  //  holds  a  list  of  affordances  that 
each  entity  can  access 

public  static  HashMap<String  ,  List>  htnParameterContainer  =  new  HashMapoQ;  //  stores  HTN  parameters 


/  *  * 

*  Adds  an  entry  to  the  gateKeeper  ,  this  function  is  called  in  the  corresponding  python  library 

*  @param  uniquelD  is  uniquelD  of  the  referenced  affordance  waypoint 

*  @param  HstOfEntitiesWithAccess  is  a  list  of  entity  IDs  that  are  allowed  to  access  the  tag’s  data 
*/ 

public  static  void  addGateKeeperEntry  ( String  uniquelD,  List  HstOfEntitiesWithAccess )  { 
workingGateKeeper  .put  (uniquelD  ,  HstOfEntitiesWithAccess); 

! 
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/  *  =t= 

*  Method 

*  at  the 

* 

*  @param 

*  @param 

*  @param 

*  @param 

*  @param 

*  @param 

*  @param 

*  @param 

*  @param 

*  @param 

*  @param 


designed  for  being  called  from  python  to  create  an  affordance  control  measure 
specified  location 

wpNamelnSits  this  string  corresponds  to  the  waypoint  name  in  Sits  (such  as  "  affordance  1  a " ) 
loc  Location  location  for  control  measure 

affordanceValidBoolean  "True"  or  "False"  —  determines  if  an  affordance  can  be  accessed  at  all 
affordanceType  ONESHOT,  PERMANENT,  TEMPORARY 
quickAccessClassifier  NONE,  ALL,  BLUE,  RED,  etc... 

validTime  sim  time  (in  seconds)  at  which  a  temporary  affordance  can  be  accessed 
cancelTime  sim  time  (in  seconds)  at  which  a  temporary  affordance  can  no  longer  be  accessed 
delay  delay  (in  seconds)  until  a  procedural  affordance  executes  an  HTN 
rangelnMeters  how  close  an  entity  needs  to  be  to  try  to  access  an  affordance 
dataType  INFORMATION,  PROCEDURE 

data  the  object  that  holds  the  actual  information  or  procedure 


*  @return  affordance  waypoint’s  unique  ID 
*/ 

public  static  String  affordanceAddControlMeasure  ( 
Location  loc  , 

String  wpNamelnSits  , 

String  affordanceValidBoolean  , 

String  affordanceType  , 

String  quickAccessClassifier  , 

String  validTime  , 

String  cancelTime  , 

String  delay  , 

String  rangelnMeters  , 

String  dataType  , 

Object  data) 


String  dataPlaceHolder  =  "None"; 
if  (dataType  .  equalsIgnoreCase("  Procedure"))} 
dataPlaceHolder  =  data  .  toString  ()  ; 

i 


//  creates  a  string  that  corresponds  to  a  waypoint’s  name 

String  affordanceName  =  wpNameInSits+"  :  "  +  affordanceValidBoolean  +  "  :  "  +  affordanceType  +  "  :  "  +  quick AccessClassifier  +  "  : 
+  validTime  +  "  :  "+cancelTime  +  "  :  "  +  delay  +  "  :  "+rangeInMeters  +  "  :  "  +  dataType  +  "  :  "  +  dataPlaceHolder  ; 

CMWayPoint  wp  =  new  CMWayPoint( 
loc  , 

affordanceName  , 

// ent . getSide ()  , 

SideType  .UNKNOWN,  //  SideType  of  UNKNOWN  because  it  doesn’t  matter 
WayPointType  .AFFORDANCE, 

Integer  .  parseInt(UniqueIDFactory.  getStringlDQ)); 

CMHolder.  addControlMeasure  (wp)  ; 

//  sets  radius  waypoint  at  which  an  entity  will  sense  an  affordance  exists  (meters) 
wp.  setTolerance(  Double  .  value  Of  (rangelnMeters))  ; 

//  updates  the  workingTagAttributeContainer  and  the  workingTagContainer 
String  wpID  =  wp.getlDQ; 

HashMap  mapOfTagAttributes  =  afford  an  ceU  ti  li  t  ie  s  .  formatWayPointName  (  affordanceName  )  ; 
workingTagAttributeContainer  .  put  (wpID  ,  mapOfTagAttributes  ) ; 
workingTagContainer.  put  (wpID  ,  data  )  ; 

return  wpID; 

i 
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/  *  * 

*  This  function  changes  the  affordanceValidBoolean  to  false;  this  is  important  to  do  after 

*  a  Temp  affordance  has  "timed  out"  or  after  a  oneShot  affordance  has  been  used 

*  Important  to  note,  this  does  not  change  the  name  that  is  included  in  the  waypoint,  this  only 

*  changes  the  affordanceValidBoolean  that  is  stored  in  the  workingTag AttributeContainer 

*  @param  uniquelD 
*1 

public  static  void  changeAffordanceValidBooleanToFalse  ( String  uniquelD)} 

String  affordanceName  =  aff ordance Utili tie s  .  getFull AffordanceName  (  uniquelD  )  ; 

HashMap  mapOfTagAttributes  =  af  ford  an  ceUti  li  t  ie  s  .  formatWayPointName  (  affordanceName  )  ; 

//  this  replaces  the  current  "True"  value  of  affordanceValidBoolean  to  "False" 
mapOfTagAttributes  .  put("  affordanceValidBoolean"  ,  "False  ") ; 
workingTagAttributeContainer  .  put(uniqueID  ,  mapOfTagAttributes)  ; 


/*  * 

*  This  function  changes  the  affordanceValidBoolean  to  True. 

*  Important  to  note,  this  does  not  change  the  name  that  is  included  in  the  waypoint,  this  only 

*  changes  the  affordanceValidBoolean  that  is  stored  in  the  workingTagAttributeContainer 

*  @param  uniquelD 
*/ 

public  static  void  change  Affordance  ValidBooleanToTrue  (  String  uniqueID){ 

String  affordanceName  =  aff  ordance  Utili  ties  .  getFull  AffordanceName  (  uniquelD  )  ; 

HashMap  mapOfTagAttributes  =  affordanceUtilities  .  formatWayPointName  (  affordanceName  )  ; 

//  this  replaces  the  current  "False"  value  of  affordanceValidBoolean  to  "True" 
mapOfTagAttributes  .  put  ("affordanceValidBoolean"  ,  "True") ; 
workingTagAttributeContainer  .  put(uniqueID  ,  mapOfTagAttributes)  ; 


/  *  * 

*  this  function  creates  an  invertedGateKeeper ;  this  object  is  used  to  tell 

*  entities  what  afford ances  they  should  be  listening  for 
*/ 

public  static  void  createlnvertedGateKeeper  ()  { 
workinglnvertedGateKeeper.  clear  ()  ; 

for  (String  uniquelD  workingGateKeeper  .  keySet  ())  { 

List  1  i  s  t O f E n  t i t i e s  =  workingGateKeeper  .  get  (  uniquelD  ) ; 
for  (Object  testEntity  listOfEntities  )  { 

String  testEntityString  =  (String)testEntity; 

if  (  workinglnvertedGateKeeper  .  con  tains  Key  (  testEntityString  )){ 

List  listToAddTo  =  workinglnvertedGateKeeper  .  remove ( t e s t En t i t y  S  tri n g  )  ; 
listToAddTo  .  add  (uniquelD)  ; 

workinglnvertedGateKeeper  .  put  ( testEntity  S  tring  ,  listToAddTo); 

i 

else  if  ( !  workinglnvertedGateKeeper  .  con  tains  Key  ( testEntityString  )){ 
ArrayList  newList  =  new  ArrayList  <>() ; 
newList .  add  (uniquelD)  ; 

workinglnvertedGateKeeper  .  put  (  testEntity  S  tring  ,  newList); 


147 


178 

179 

180 

181 

182 

183 

184 

185 

186 

187 

188 

189 

190 

191 

192 

193 

194 

195 

196 

197 

198 

199 

200 

201 

202 

203 

204 

205 

206 

207 

208 

209 

210 

211 

212 

213 

214 

215 

216 

217 

218 

219 

220 

221 

222 

223 

224 

225 

226 

227 

228 

229 

230 

231 

232 

233 

234 

235 

236 

237 

238 

239 

240 

241 

242 


} 

else  { 

System,  out  .  print  ("AN  ERROR  OCCURRED  WHILE  CREATING  THE  in  vertedGateKeeper " )  ; 

i 


/  *  =t= 


*  @param  wpNamelnSits 

*  @param  HstOfEntitiesWithAccess 

*  @param  affordanceValidBoolean 

*  @param  affordanceType 

*  @param  quickAccessClassifier 

*  @param  validTime 

*  @param  cancelTime 

*  @param  delay 

*  @param  rangelnMeters 

*  @param  dataType 

*  @param  data 

*  @return 

*  / 

public  static  String  createNewAffordance  (  String  wpNamelnSits, 

List  HstOfEntitiesWithAccess  , 

List  listOfUnits  With  Access  , 

String  affordanceValidBoolean  , 

String  affordanceType  , 

String  quickAccessClassifier  , 

String  validTime  , 

String  cancelTime  , 

String  delay  , 

String  rangelnMeters  , 

String  dataType  , 

Object  data){ 

//  creates  a  new  affordance  waypoint  (this  line  creates  the  WP,  makes  an  entry  in  the  tag AttributeContainer  , 

makes  entry  in  tagContainer  ,  and  returns  the  unique  ID  for  later  use) 

ControlMeasure  currentControlMeasure  =  CMHolder .  retrieveControlMeasureByName  (  wpNamelnSits )  ; 

String  uniquelD  =  affordance AddControlMeasure  (  currentControlMeasure  .  getLocation  ()  , 

wpNamelnSits  , 
affordanceValidBoolean  , 
affordanceType  , 
quickAccessClassifier  , 
validTime  , 
cancelTime  , 
delay  , 

rangelnMeters  , 
dataType  , 
data )  ; 

List<String>  HstOfEntityNames  =  getArrayListOfEntityNames  (  HstOfUnitsWithAccess  )  ; 

for  (String  entityName  :  HstOfEntityNames )  { 

HstOfEntitiesWithAccess  .  add  (  entityName  )  ; 

i 


//  create  appropriate  entry  in  gateKeeper 
addGateKeeperEntry  (uniquelD  ,  HstOfEntitiesWithAccess)  ; 
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boolean  printBasicAffordancelnfoBoolean  =  true; 
if  (printBasicAffordanceInfoBoolean){ 

System  .  out .  println  ("  affordance  uniquelD  =  ”  +  uniqueID); 

System  .  out  .  println  ("  affordance  data  =  "  +  data  .  toString  ()  )  ; 

System  .  out  .  println  ("HstOfEntitiesWithAccess  =  "  +  listOfEntitiesWithAccess  .  toString  () )  ; 
System  .out.  println  ("quickAccessClassifier  =  "  +  quickAccessClassifier); 

System  .  out  .  println  ()  ; 


return  uniquelD  ; 


/  *  * 

*  determines  if  a  uniquelD  corresponds  to  an  Affordance  (used  to  determine  if  ControlMeasure  is  an  Affordance) 

*  used  in  processAffordancesTree 

*  @param  uniquelD 

*  @return 
*/ 

public  static  boolean  determinelf Affordance  ( String  uniqueID){ 
return  workingTagContainer.  containsKey(  uniquelD)  ; 

! 


//  BEGIN  entity AttemptToAccess Affordance  FUNCTION 

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////// 

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////// 

/  *  * 

*  this  block  of  code  determines  whether  or  not  an  entity  is  allowed  to  access  affordance  data 

*  @param  ent 

*  @param  uniquelD 

*  @return  affordance  data  if  the  entity  has  access  (null  if  the  entity  does  not  have  access) 

*/ 

public  static  Object  entityAttemptToAccessAffordance  ( Entity  ent,  String  uniqueID){ 


////////////////////////////////////////////////////////////////////////////////////////////////// 

//  this  line  checks  whether  or  not  an  affordance  is  valid;  if  not,  the  method  immediately  exits 
//  this  is  mostly  applicable  to  oneShots  that  have  been  used  or  temps  that  have  "timed  out" 

String  affordanceValidBoolean  =  affordanceUtilities  .  get  Affordance  Attribute  (uniquelD  ,  "  affordance  ValidBoolean  ") ; 
if  (  affordance  ValidBoolean  .  equalsIgnoreCase  ("  False  ") )  { 
return  null  ; 

} 


//////////////////////////////////////////////////////////////////////////////////////////////// 
//  set  "local"  variables  that  will  be  used  within  this  function 
boolean  accessGranted  =  false  ; 
boolean  isAffordanceTemp  =  false  ; 


/////////////////////////////////////////////////////////////////////////////////////////////////// 
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//  collects  and  organizes  information  about  the  affordance  ,  and  the  entity  attempting  to  access  the  affordance 


//  determines  information  concerning  the  entity  that  is  trying  to  access  the  affordance 
SideType  thisEntitySideType  =  ent  .  getSide  ()  ; 

String  thisEntityName  =  ent .  getAssignedName  ()  ; 

//  this  block  of  code  retrieves  and  formats  the  tag’s  name 

ControlMeasure  affordanceAttemptingToAccess  =  CMHolder .  retrieveControlMeasureBylD  (  uniquelD  )  ; 

String  quickAccessClassifier  =  affordanceUtilities  .  getAffordance Attribute  (uniquelD  ,  "  quickAccessClassifier  " )  ; 
String  affordanceType  =  af  fordanceUtilities  .  get  AffordanceAttribute  (  uniquelD  ,  "  affordanceTy pe  "  )  ; 

if  (affordanceType  .  equalsIgnoreCase(  "TEMPORARY" ) )  { 
isAffordanceTemp  =  true  ; 

} 


////////////////////////////////////////////////////////////////////////////////////////////////// 

//  determines  if  temp  affordances  are  valid  ,  if  not  ,  access  to  affordance  data  is  denied 
//  and  the  entire  entity  AttemptTo  Access  Affordance  function  exits  .  Additionally  ,  if  the  affordance  has 
//  timed  out  ,  it  changes  the  affordanceValidBoolean  to  false 
if  (isAffordanceTemp)  { 

Double  currentSimTime  =  Schedule .  getSimTime  ()  ;  //  use  this  value  to  test  if  affordance  is  valid 

Double  validTime  =  Double  .  valueOf  (  affordanceU  tili  tie  s  .  get  Affordance  Attribute  (  uniquelD  ,  "  validTime  " ) )  ; 

Double  cancelTime  =  Double  .  valueOf  (  affordanceUtilities  .  get  AffordanceAttribute  (  uniquelD  ,  "  cancelTime  " ) )  ; 

if  (currentSimTime  <  validTime){ 

System  .  out .  println  ("")  ; 

System  .  out .  println  (  "TEMPORARY  affordance  is  not  valid  yet;  ACCESS  DENIED"); 

System  .  out .  println  ("")  ; 
return  null  ; 

i 


if  (currentSimTime  >=  cancelTime){ 

affordanceUtilities  .  changeAffordanceValidBooleanToFalse(  uniquelD)  ; 

System,  out .  println  ("")  ; 

System .  out .  println  ( "TEMPORARY  affordance  has  timed  out;  ACCESS  DENIED  and  affordanceValidBoolean  changed 
to  False"); 

System,  out .  println  ("")  ; 
return  null  ; 


//////////////////////////////////////////////////////////////////////////////////////////// 
//  this  block  determines  if  an  entity  can  access  an  affordance 

//  if  the  quickAccessClassifier  value  is  "ALL"  then  it  grants  the  entity  access  to  the  data 
if  (  quickAccessClassifier  .  equalsIgnoreCase  ( "ALL" ) )  { 
accessGranted  =  true  ; 

i 

//  determines  if  entity  attempting  to  access  matches  the  quickAccessClassifier  value 
else  if  ( thisEntitySideType  .  toString  ()  .  equalsIgnoreCase  (quickAccessClassifier))} 
accessGranted  =  true  ; 

) 


//  if  entity  does  not  match  quickAcces sClassifierV alue  ,  it  checks  if  entity  is  on  the  tag’s  GateKeeper  access 
list 
else  { 

List  listToCheck  =  workingGateKeeper  .  get  (  uniquelD  )  ; 
if  ( listToCheck  .  contains  ( thisEntityName  ) )  { 
accessGranted  =  true  ; 

i 

i 
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////////////////////////////////////////////////////////////////////////////////////////////////// 
//  returns  the  data  if  access  has  been  granted 
if  (  accessGranted  )  { 

return  workingTagContainer  .  get(uniquelD)  ; 


else  { 

return  null  ; 


//////////////////////////////////////////////////////////////////////////////////////////////////////////////////// 
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////// 
//  end  entity AttemptToAccessAffordance  function 


/  *  * 

*  this  function  formats  an  affordance  name  (in  string  format)  into  a  hashmap  which  is  easier  to  access 

*  this  is  the  primary  function  to  update  if  one  changes  the  format  of  an  affordance’ s  name 

* 

*  @param  wayPointNameString 

*  @return  returns  a  HashMap  that  has  organized  the  name  of  a  waypoint 
*/ 

public  static  HashMap  formatWayPointName  (  String  wayPointNameString  )  { 

HashMap<String  ,  Object>  formattedWayPointName=  new  HashMap<>(); 

String  stringToParse  =  wayPointNameString; 

String  []  arrayOfStrings  =  stringToParse  .  s  p  1  i  t  ; 

String  wpNamelnSits  =  arrayOfStrings  [0] ; 

String  affordanceValidBoolean  =  arrayOfStrings  [  1  ] ; 

String  affordanceType  =  arrayOfStrings  [2] ; 

String  quickAccessClassifier  =  arrayOfStrings  [3] ; 

String  validTime  =  arrayOfStrings  [4] ; 

String  cancelTime  =  array OfStrings  [5 ] ; 

String  delay  =  arrayOfStrings  [6] ; 

String  rangelnMeters  =  arrayOfStrings  [7] ; 

String  dataType  =  arrayOfStrings  [8] ; 

String  data  =  arrayOfStrings  [9] ; 

for  mat  ted  Way  Point  Name  .  put  ( "  wpNamelnSits "  ,  wpNamelnSits  ) ; 

for  mat  ted  Way  Point  Name  .put  ("affordanceValidBoolean"  ,  affordanceValidBoolean); 

for  matted  W  ay  PointName  .  put("  affordanceType"  ,  affordanceType) ; 

for  matted  Way  Point  Name  .put  ("quickAccessClassifier"  ,  quickAccessClassifier); 

for  mat  ted  Way  PointName  .  put(  "validTime"  ,  validTime)  ; 

for  matted  Way  Point  Name  .  put("  cancelTime"  ,  cancelTime  )  ; 

formattedWayPointName  .  put  ( "  delay  "  ,  delay  )  ; 

for  mat  ted  Way  Point  Name  .  put("  rangelnMeters"  ,  rangelnMeters); 

formattedWayPointName  .  put  ("  dataType  "  ,  dataType  )  ; 

formattedWayPointName  .  put  ( "  data  "  ,  data  ) ; 

return  formattedWayPointName; 

! 
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/*  * 

*  This  affordanceUtilities  "internal"  function  gets  an  attribute  for  a  specific  affordance 

*  @param  unique  ID 

*  @param  attributeType 

*  @return  the  desired  affordance  attribute 
*/ 

public  static  String  get  Affordance  Attribute  (  String  uniquelD  ,  String  attributeType  )  { 

String  affordanceAttribute  =  wo  rkingTagAttributeContainer.  get  (uniquelD).  get  (attributeType).  toStringQ  ; 
return  affordanceAttribute  ; 

i 


/  *  * 

*  this  is  an  important  function  that  aids  in  letting  an  HTN  change  an  specific  affordance’s  affordanceValidBoolean 

*  @param  wayPointNamelnSits 

*  @return  an  affordance’s  uniquelD 
*/ 

public  static  String  get  AffordanceUniquelD  (  String  wayPointNamelnSits  )  { 

Set  setOf AffordanceUniquelDs  =  getSetOf AffordanceUniquelDs  ()  ; 

String  uniquelD  =  null  ; 

for  (Object  value  setOf  AffordanceUniquelDs )  { 

String  testUniquelD  =  value  .  toString  ()  ; 

String  test  Attribute  =  get  AffordanceAttribute  ( testUniquelD  ,  "  wpNamelnSits  "  )  ; 
if  (  testAttribute  .  equalsIgnoreCase(  wayPointNamelnSits  )  )  { 
uniquelD  =  testUniquelD  ; 
break  ; 

i 

i 

if  (uniquelD  ==  null  )  { 

System  .  out  .  println  (  "AN  ERROR  OCCURRED  IN  GET AFFORD ANCEUNIQUEID "  )  ; 

i 


return  uniquelD  ; 

) 


public  static  ArrayList  <String  >  get ArrayListOfEntityNames  (  List  <String  >  listOfUnitNames  )  { 

ArrayList  <String  >  arrayListOfEntityNames  =  new  ArrayList  <>() ; 

for  (String  unitName  listOfUnitNames  )  { 

OperationalGroup  unit  =  NewUnitHolder  .  retrieveUnitByName  (  unitName )  ; 

List<Entity>  listOfEntities  =  unit  .  get  AllUnitMembers  ()  ; 
for  (Entity  currentEntity  listOfEntities  )  { 

String  currentEntityName  =  currentEntity  .  getAssignedName  ()  ; 
arrayListOfEntityNames  .  add  (  currentEntityName  )  ; 

i 

i 

return  arrayListOfEntityNames; 

i 
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/  *  =t= 

*  used  in  process AffordancesTree  ,  haveEntityListenFor Affordances  node 

*  @param  uniquelD 

*  @return 
*/ 

public  static  ControlMeasure  getControlMeasure  ( String  uniqueID){ 

ControlMeasure  currentCM  =  CMHolder .  retrie  veControlMeasure  (  uniquelD  )  ; 
return  currentCM; 


/  5|C  * 

*  gets  an  affordances  ’  s  full  name 

*  this  is  used  to  change  the  value  of  an  affordanceValidBoolean 

*  @param  uniquelD 

*  @return 
*/ 

public  static  String  getFullAffordanceName  ( String  uniqueID){ 

ControlMeasure  workingCM  =  CMHolder .  retrie  veControlMeasure  (  uniquelD  )  ; 
String  affordanceName  =  workingCM  .  getName  ()  ; 
return  affordanceName; 

i 


/  *  * 

*  this  is  used  in  process  AffordancesTree  haveEntitiesListenFor  Affordances 

*  @param  entity 

*  @return 
*1 

public  static  List  getListOf  AffordancesEntityCan  Access  (  String  entity){ 
return  workinglnvertedGateKeeper  .  get(  entity  )  ; 

! 


/  *  * 

*  this  is  used  to  get  HTN  parameters 

*  IMPORTANT  TO  NOTE  THAT  THIS  IS  A  DEEP  COPY  OF  THE  HTN  PARAMETERS 

*  @param  wpNamelnSits 

*  @return  parameterList 
*/ 

public  static  List  getListOfHtnParameters  (  String  wpNamelnSits )  { 
List  parameterList  =  htnParameterContainer  .  get  ( wpNamelnSits )  ; 
// System  .  out  .  print  In  ("PARAMETER  LIST  FROM  JAVA")  ; 

//System,  out  .  println  (parameterList  .  toString  () )  ; 


node 
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return  parameterList ; 


/  *  * 

*  used  in  processAffordanceHTN  ( haveEntity ListenForAffordances  node) 

*  used  in  conjunction  with  getAffordanceUniquelD  (optional  usage  here) 

*  @return  setOfAffordanceUniquelDs 
*1 

public  static  Set  getSetOf AffordanceUniquelDs  ()  { 

Set  setOfAffordanceUniquelDs  =  workingGateKeeper  .  keySet  ()  ; 
return  setOfAffordanceUniquelDs; 


/  *  * 

*  this  is  used  to  initially  set  and  later  update  (if  required)  HTN  parameters 

*  @param  wpNamelnSits 

*  @param  listOfParameters 
*/ 

public  static  void  updateHtnParameterContainer  ( String  wpNamelnSits,  List  listOfParameters )  { 
htnParameterContainer  .  put(  wpNamelnSits  ,  listOfParameters); 

// System  .  out .  println  ("  updateHtnParameterContainer  method  is  complete"); 

//System,  out .  println  (htnParameterContainer  .  toString  () )  ; 

i 


D.2  changeAffordanceValidBoolean.xml 

The  primary  function  of  this  HTN  is  to  change  an  affordance’s  “affordanceValidBoolean.” 
When  used  as  part  of  a  procedural  affordance,  this  feature  can  be  used  to  activate,  reactivate, 
or  deactivate  designated  affordances. 

<?xml  version  =  "  1 .0  "  encoding  =  "UTF— 8"  standalone  =  "no"  ?><HTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name=" 

changeAffordanceValidBoolean"  Type="DEFAULT"xParent>null<  /  Parent ><DataMap><DataKey>typeChange  ,java  .  lang  .  String</ 
DataKeyxDataKey>affordancesToChangeList  ,  java  .  util  .  ArrayListc/DataKeyx/DataMapxCode  IsFile="  false  "/xlmport/x 
HTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name="  initlnfo  "  Type="DEFAULT"xParent>changeAffordanceValidBoolean</ Parent 
xCode  IsFile  =  "  false  ">if  _gt_acti veNode  .  getVar  ( "  islnited  " )  ==  None: 

_gt_activeNode  .  putVar("  islnited",  1) 

_htn_precon_ret=l 

</  Codexlmport  /xHTNNode  AllowMsg="  false"  BreakPoints  =  "”  Name="  makeChanges "  Type="GOAL"xParent>  i  ni  1 1  nf  o  <  /  Parent  xCode 
IsFile  =  "  false  ">from  cxxi  .  model .  behavior  import  OrderUtilities 
import  UtilityFuncs 
from  HTN  import  UtilityFuncsExp 
from  java,  util  import  Set 
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from  mtry  .  cxxi  .  model .  affordances  import  affordanceUtilities 
import  copy 


typeChange  =  _gt_activeNode  .  getParam  ( "  typeChange  "  ) 

afford ancesToCh an geList  =  _gt_activeNode.  getParam  ("affordancesToChangeList") 


#  changes  affordance ValidB ooleans  to  the  opposite  of  their  current  value 
if  typeChange  ==  "SWITCH”: 

for  wpNamelnSits  in  affordancesToChangeList: 
wpNamelnSitsString  =  str  (wpNamelnSits) 

uniquelD  =  affordanceUtilities  .getAffordanceUniqueID(  wpNamelnSitsString) 

affordanceValidBoolean  =  affordanceUtilities.getAffordanceAttribute(  uniquelD  ,  "affordanceValidBoolean") 
if  affordanceValidBoolean  ==  "True": 

affordanceUtilities  .  change  Affordance  ValidBooleanToFalse  (uniquelD) 

printMessage  ( "  changeAffordanceValidBoolian  uniquelD  "+  s  tr  (  uniquelD  )  +  "  changed  to  False",  True) 
elif  affordanceValidBoolean  ==  "False": 

afford  anceUtilities.changeAffordanceValidBooleanToTrue(  uniquelD) 

printMessage  ("  changeAffordanceValidBoolian  uniquelD  "+  s  tr  (  uniquelD  )  +  "  changed  to  True",  True) 
else: 

printMessage  ("  !  !  !  !  !  ERROR  OCCURRED  IN  CHANGEAFFORDANCEVALIDBOOLEAN  HTN"  ,  True) 


#  changes  all  affordanceValidBooleans  to  True  (regardless  of  their  current  value) 
elif  typeChange  ==  "ALLTRUE" : 

for  wpNamelnSits  in  affordancesToChangeList: 
wpNamelnSitsString  =  str  ( wpNamelnSits  ) 

uniquelD  =  affordanceUtilities.  get  AffordanceUniqueID(  wpNamelnSitsString  ) 

affordanceValidBoolean  =  affordanceUtilities.  getAffordanceAttribute  (uniquelD  ,  "affordanceValidBoolean") 
affordanceUtilities  .  changeAffordanceValidBooleanToTrue  (uniquelD) 

printMessage  ("  change  Affordance  ValidBoolian  uniquelD  "  +  str  ( uniquelD  )  +  "  changed  to  True",  True) 


#  changes  all  affordanceValidBooleans  to  False  (regardless  of  their  current  value) 
elif  typeChange  ==  "ALLFALSE"  : 

for  wpNamelnSits  in  affordancesToChangeList: 
wpNamelnSitsString  =  str  ( wpNamelnSits  ) 

uniquelD  =  affordanceUtilities.  get  Af  ford  anceUniqueID(  wpNamelnSitsString  ) 

affordanceValidBoolean  =  affordanceUtilities.  getAffordanceAttribute  (uniquelD  ,  "affordanceValidBoolean") 
affordanceUtilities  .  change  Affordance  ValidBooleanToFalse  (uniquelD) 

printMessage  ("  change  Affordance  ValidBoolian  uniquelD  "  +  str  ( uniquelD )  +  "  changed  to  False",  True) 


else: 

printMessage  (""  ,  False) 

printMessage  ("  error  in  change  AffordanceValidBoolean  .  xml"  ,  False) 
printMessage(""  ,  False  )</CodexImport  /></HTNNodex/HTNNodex/HTNNode> 


D.3  processAffordances.xml 

When  added  to  an  entity’s  goal  stack,  this  HTN  enables  entities  to  detect  and  process  affor¬ 
dances. 


<?xml  version  =  "  1 .0  "  encoding  =  "UTF— 8"  standalone  =  "  no "  ?><HTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name="  process  Affordances  " 
Type=”DEFAULT"xParent>null</ ParentxCode  IsFile="  false  " /xlmport /xHTNNode  AllowMsg="  true  "  BreakPoints  =  "  "  Name=" 
ini  t Info  "  Type="DEFAULT"xParent>processAffordances<  /  ParentxCode  IsFile  =  "  false  ">if  _gt_activeNode  .  getVar(" 
islnited  " )  ==  None: 

_gt_activeNode  .putVar("  islnited",  1) 

_htn_precon_ret=l 

</ Codexlmport  /xHTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name="  addReplanTriggers  "  Type="DEFAULT"xParent>initInfo</  Parent 
xCode  IsFile  =  "  false  ">#  model  events 
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goalContainer  .  getCurrentExecutingStackQ  .  addReplanTrigger(”  AtAControlMeasure  " ) 


#  HTN  events 

goalContainer  .  getCurrentExecutingStackQ  .  addReplanTrigger("GoalTracker_StopAffordanceTree")</ Codexlmport /></HTNNode>< 
HTNNode  AllowMsg="  fal se  "  BreakPoints  =  " "  Name="  haveEntityListenForAffordances  "  Type="DEFAULT"xParent>initInfo</ 
ParentxCode  IsFile  =  "  false  ">from  cxxi  .  model .  behavior  import  OrderUtilities 
import  UtilityFuncs 
from  HTN  import  Utility FuncsExp 
from  java,  util  import  Set 

from  mtry  .  cxxi  .  model .  affordances  import  affordanceUtilities 


#  this  tells  entities  to  listen  for  affordances  they  have  access  to  and  that  do  not  use  the  quickAccessClassifier 
feature 

listOfAffordancesEntityCanAccess  =  affordanceUtilities  .getListOfAffordancesEntityCanAccess(info  .  getMyAssignedName  () ) 
if  HstOfAffordancesEntityCanAccess: 
printMessage  ( " "  ,  False) 

printMessage  ("  listOf  AffordancesEntity  Can  Access  (not  including  quickAccessClassifier  affordances)  =  "  +  str( 
listOf AffordancesEntityCan Access  )  ,  True) 
printMessage  (""  ,  False) 

for  uniquelD  in  listOfAffordancesEntityCanAccess: 

currentCM  =  af ford anceU t  i  li tie s  .  getControlMeasure  (  uniquelD  ) 
state  .addControlMeasure  (currentCM  .  getName  () ) 


#  this  tell  entities  to  listen  for  affordances  that  utilize  the  appropriate  quickAccessClassifier  feature 
setOfAffordanceUniquelDs  =  affordanceUtilities  .getSetOfAffordanceUniquelDsQ 
for  uniquelD  in  setOfAffordanceUniquelDs: 

affordanceQuickAccessClassifier  =  affordanceUtilities  ,getAffordanceAttribute(  uniquelD  ,  "quickAccessClassifier") 
if  affordanceQuickAccessClassifier  ==  "ALL": 

currentCM  =  affordanceUtilities  .  getControlMeasure  (  uniquelD  ) 
state  .addControlMeasure  (currentCM  .  getName  () ) 
elif  affordanceQuickAccessClassifier  ==  s  tr  ( info  .  getMySide  () ) : 
currentCM  =  affordanceUtilities  .  getControlMeasure  (  uniquelD  ) 

state  .addControlMeasure  (currentCM  .  getName  ()  )</  Codexlmport  /x/HTNNodexHTNNode  AllowMsg="  false"  BreakPoints  =  ”"  Name= 
"  endlnit "  Type="INTERRUPT"xParent>initInfo<  /  ParentxCode  IsFile  =  "  false  ">printMessage("processAffordancesTree  IN  IT 
FINISHED",  True) 

printMessage  (""  ,  False  )</CodexImport /x/HTNNodex/HTNNodexHTNNode  AllowMsg=”  true  "  BreakPoints  =  " "  Name="  events  "  Type=" 
DEFAULT"xParent>  pro  cess  Affordances<  /  ParentxCode  IsFile=”  false  ">_htn_precon_ret  =  l</ Codexlmport  /xHTNNode 
AllowMsg="  true  "  BreakPoints  =  " "  Name="  isGoalTrackerEvent "  Type="DEFAULT"xParent>events</ ParentxCode  IsFile  =  "  false 
">if  state  .  getLastTriggerQ  .  startswith("  doGoalTracker_ " )  : 

_htn_precon_ret  =  l</CodexImport /xHTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name="  isStopAffordanceTree  "  Ty pe=" DEFAULT "x 
Parent>isGoalTrackerEvent</ ParentxCode  IsFile  =  "  false  ">if  state  .  getLastTrigger  ()  ==  " 
doGoalT  racker_S  top  Afford  anceTree  " : 

_htn_precon_ret=l</CodexImport /xHTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name="  stopAffordanceTree  "  Type="GOAL"xParent 
>isStopAffordanceTree</ ParentxCode  IsFile  =  "  false  ">#  this  node  provides  the  option  of  having  an  entity  stop 
listening  for  affordances 

printMessage  (""  ,  False) 

printMessage  ("ENTITY  HAS  STOPPED  ITS  AFFORDANCE  TREE",  True) 

printMessage  (""  ,  False  )</CodexImport /x/HTNNodex/HTNNodex/HTNNode><HTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name=" 

modelEvents"  Type="DEFAULT"xParent>e vents </  ParentxCode  IsFile="  false  ">_htn_precon_ret=l</ Codexlmport  /  xHTNNode 
AllowMsg="  true  "  BreakPoints  =  " "  Name="  is  At  AControlMeasure  "  Type="DEFAULT"xParent>modelEvents</ ParentxCode  IsFile  = 
"false">if  state  .  getLastTrigger  ()  ==  "  doAtAControlMeasure  "  : 

_htn_precon_ret=l</CodexImport /xHTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name="  is Affordance  "  Type="DEFAULT"xParent> 
isAt AControlMeasure</ ParentxCode  IsFile  =  "  false  ">from  cxxi  .  model .  behavior  import  OrderUtilities 
import  UtilityFuncs 
from  HTN  import  UtilityFuncsExp 
from  java,  util  import  Set 

from  mtry  .  cxxi  .  model .  affordances  import  affordanceUtilities 


#  this  code  is  triggered  because  an  entity  has  come  within  range  of  a  control  measure 

#  this  code  determines  if  that  control  measure  is  an  affordance 

currentCM  =  state  .  getLastTriggerParams  ()  [0] 
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uniquelD  =  currentCM  .  getID  ( ) 


if  affordanceUtilities  .  determinelf Affordance  (  uniquelD  )  : 

_gt_activeNode  .  putVar  ( "  currentCM  "  ,  currentCM  ) 

_gt_activeNode  .putVar  ("uniquelD",  uniquelD) 

_htn_precon_ret  =  l</Code><Import /xHTNNode  AllowMsg="  false  "  BreakPoints  =  " "  Name="  isEntityHaveAccessToAffordance  "  Type= 
DEFAULT"xParent>is Affordancec/  ParentxCode  IsFile  =  "  false  ">from  cxxi  .  model .  behavior  import  OrderUtilities 
import  UtilityFuncs 
from  HTN  import  Utility FuncsExp 
from  java,  util  import  Set 

from  mtry  .  cxxi  .  model .  affordances  import  affordanceUtilities 


uniquelD  =  _gt_activeNode  .  get  Var  ("  uniquelD  "  ) 


#  checks  to  see  if  an  entity  can  access  an  affordance 

#  if  access  is  access  is  not  granted  ,  then  affordanceData  is  null 

afford anceData  =  affordanceUtilities  .entityAttemptToAccessAffordance(info.getMySelf()  ,  uniquelD) 

_gt_activeNode  .putVar  ("  affordanceData"  ,  affordanceData) 

if  affordanceData: 

_htn_precon_ret=l 

elif  not  affordanceData: 
printMessage  ( " "  ,  False) 

printMessage  ("  access  denied  to  affordance  number"  +  str  (  uniquelD  )  ,  True) 
printMessage  ,  False) 

else: 

printMessage  ( "ERROR  IN  isEntityHaveAccessToAffordance",  True) 

</CodexImport /xHTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name="  execute  Affordance  "  Type="DEFAULT"xParent> 

isEntityHaveAccessTo Affordancec/ ParentxCode  IsFile  =  "  false  ">from  cxxi .  model .  behavior  import  OrderUtilities 
import  UtilityFuncs 
from  HTN  import  Utility  FuncsExp 
from  java,  util  import  Set 

from  mtry  .  cxxi  .  model .  affordances  import  affordanceUtilities 
import  copy 


#  gets  information  about  the  affordance  that  will  be  used  in  its  execution 
uniquelD  =  _gt_activeNode  .  get  Var  ("  uniquelD  " ) 

dataType  =  affordanceUtilities  .  get  Affordance  Attribute  (  uniquelD  ,  "dataType") 
affordanceType  =  affordanceUtilities  .  get  Affordance  Attribute  (  uniquelD  ,  "  affordanceType  " ) 
wpNamelnSits  =  affordanceUtilities  .  get  Affordance  Attribute  (  uniquelD  ,  "  wpNamelnSits  " ) 


printMessage  (""  ,  False) 
printMessage  (""  ,  False) 

printMessage  ("ACCESS  GRANTED  TO  AFFORDANCE"  ,  True) 
printMessage  ("  affordanceType  =  "  +  str  (  affordanceType  )  ,  True) 
printMessage  ("  wpNamelnSits  =  "+ str  ( wpNamelnSits )  ,  True) 


#  this  block  of  code  runs  if  the  Affordance  is  of  type  PROCEDURE 
if  dataType  ==  "PROCEDURE": 

currentParameterList  =  affordanceUtilities  .  getListOfHtnParameters  (wpNamelnSits) 
shallowCopyCurrentParameterList  =  copy  .  copy  (currentParameterList) 
delay  =  affordanceUtilities  .  get  Affordance  Attribute  (uniquelD  ,  "delay") 
delayFloat  =  float(delay) 

affordanceData  =  _gt_activeNode  .  getVar( "  affordanceData  " ) 
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goalPath  =  affordanceData 


printMessage  ("  executing  a  procedural  affordance".  True) 
printMessage  ("  goalPath  =  "+ str  (  goalPath  )  ,  True) 

printMessage  ("  affordance  parameter  list  =  "+ str  (  currentParameterList )  ,  True) 

UtilityFuncsExp  .  addGoal( 
info  .  getMyAssignedName  ( )  , 
delayFloat  , 
goalPath  , 

shallowCopy CurrentParameterList  , 

None) 

if  affordanceType  ==  "ONESHOT"  : 

affordanceUtilities.changeAffordanceValidBooleanToFalse(uniquelD) 
printMessage  (  "AFFORDANCE  VALID  BOOLEAN  CHANGED  TO  FALSE"  ,  True) 


#  this  block  of  (yet  to  be  written)  code  runs  if  the  Affordance  is  of  type  INFORMATION 
elif  dataType  ==  "INFORMATION": 

printMessage  ("  attempting  to  execute  an  informational  affordance".  True) 


else: 


printMessage  ( "ERROR  IN  execute  Affordance  "  ,  True  )</CodexImport /></HTNNodex/HTNNodexHTNNode  AllowMsg="  false  " 

BreakPoints  =  ""  Name="  stopListeningForAffordance"  Type=  "DEFAULT"  x  Par  en  t  >isAf  for  dance  <  /  Parent  xCode  IsFile  =  "  false  "> 
#  stops  entity  from  listening  for  this  Affordance 

#  IMPORTANT  TO  REALIZE  REPERCUSSIONS  OF  THIS  CODE 

#  IF  AN  ENTITY  COMES  ACROSS  AN  AFFORDANCE  ONCE  AND  IS  DENIED  ACCESS, 

#  THEN  THE  ENTITY  WILL  NO  LONGER  BE  LISTENING  FOR  THE  AFFORDANCE 

currentCM  =  _gt_activeNode  .  getVar(  "currentCM" ) 

state  .  removeControlMeasure  ( currentCM  .  getName  ()  ) 

printMessage  ("  stopListeningForAffordance  node  finished",  True  )</CodexImport /x/HTNNodexHTNNode  AllowMsg="  f  al  se  " 

BreakPoints  =  ""  Name="  noWorkLeft "  Type="INTERRUPT"xParent>is  Affordance<  /  Parent  xCode  IsFile="  false  ">printMessage(" 
no  work  left"  ,  True)</Codex Import  / ></ HTNNodex / HTNNodex / HTNNodex / HTNNodex / HTNNodex / HTNNode> 


When  added  to  an  entity’s  goal  stack,  this  HTN  brings  the  entity’s  processAjfordances 
HTN  to  a  goal  state,  thus  preventing  the  entity  from  detecting  and  accessing  additional 
affordances. 


<?xml  version  =  "  1 .0  "  encoding  =  "UTF— 8"  standalone  =  "no"  ?><HTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name=" 

stopProcessAffordancesHTN"  Type="DEFAULT"xParent>null<  /  Parent  xCode  IsFile="  false  "  /  ><  Import  /xHTNNode  AllowMsg=" 
true"  BreakPoints  =  " "  Name="  initlnfo  "  Type="DEFAULT"xParent>stopProcessAffordancesHTN</ ParentxCode  IsFile  =  "  false  " 
>if  _gt_activeNode  .  getVar  ( "  i  s I n i  t e d  " )  ==  None: 

_gt_activeNode  .putVar("isInited",  1) 

_htn_precon_ret=l 

</CodexImport /xHTNNode  AllowMsg="  false  "  BreakPoints  =  " "  Name="  fireStopAffordanceTree  "  Type="GOAL"xParent>initInfo</ 
ParentxCode  IsFile  =  "  false  ">from  HTN  import  UtilityFuncsExp 

printMessage  (""  ,  False) 

printMessage  ("  fireStopAffordanceTree  node  activated".  True) 

printMessage  (""  ,  False) 

UtilityFuncsExp  .  scheduleEvent( 
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info  .  getMyAssignedName  ()  , 
"GoalTracker_StopAffordanceTree", 
0.001  . 

None) 


<  /  Code  x  I  m  p  o  r  t  /  ><  /  HTNNodex  /  HTNNodex  /  HTNNode> 


D.5  templateAffordancelnitialization.py 

This  script  can  be  used  as  a  template  for  the  creation  of  scenario-specific  ajfordancelnitial- 
ization  files. 

from  mtry  .  cxxi  .  model .  HierarchicalTaskNetwork  import  GoalContainer 

from  cxxi  .  model .  objects  .  holders  import  CMHolder 

from  java,  util  import  ArrayList 

from  cxxi  .  model .  behavior  import  OrderUtilities 

import  UtilityFuncs 

from  HTN  import  UtilityFuncsExp 

from  java,  util  import  Set 

from  mtry  .  cxxi  .  model .  affordances  import  affordanceUtilities 
import  math 


#  print  a  debug  message 
print  " " 

print  "start  affordancelnitialization" 
print  " " 


################################################################################### 
#  5  STEP  PROCESS  TO  SET  UP  SCENARIO  AFFORDANCES 
################################################################################### 


#  STEP  1  -  SITS 

################################################################################### 

#  Place  (normal)  waypoints  in  SITS  scenario  file  that  correspond  to  desired  affordance  locations 

#  Give  these  waypoints  a  name  that  is  in  accordance  with  your  affordance  naming  convention  (ie  —  affordance  1  a ) 

#  If  using  HTNs  that  require  locations  as  parameters  ,  place  create  these  waypoints  as  well 

#  If  desired  ,  the  waypoints  marking  the  affordance  location  can  double  as  an  HTN  parameter 


#  STEP  2  -  WRITE  CODE  TO  INITIALIZE  AFFORDANCES 
################################################################################### 

# 

#  THREE  PART  PROCESS 

#  A:  create  the  affordance  using  affordanceUtilities  .  createNewAffordance  ()  method 

#  B:  create  a  list  of  parameters  to  be  used  with  an  HTN  (if  required) 

#  C:  store  the  list  of  HTN  parameters  using  affordanceUtilities  .  updateHtnParameterContainer  ()  method  (if  required) 

# 

#  EXPLANATION  OF  PARAMETERS  USED  WHEN  CREATING  A  NEW  AFFORDANCE 

#  affordanceUtilities  .  createNewAffordance  (  wayPointNameFromSits  where  affordance  is  to  be  located, 

#  list  of  entity  names  who  can  access  affordance  (can  be  empty) 

#  list  of  unit  names  whose  entities  can  access  affordance  (can  be  empty) 

#  affordanceValidBoolean  (True  or  False), 

#  affordanceType  (PERMANENT,  ONESHOT,  OR  TEMPORARY)  , 

#  quickAccessClassifier  (NONE,  ALL,  BLUE,  RED,  GREEN,  etc...), 


159 


50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 

100 

101 

102 

103 

104 

105 

106 

107 

108 


# 

# 

# 

# 

# 

# 


time  in  seconds  at  which  a  TEMPORARY  affordance  becomes  valid  , 
time  in  seconds  at  which  a  TEMPORARY  affordance  becomes  invalid  , 

delay  in  seconds  until  a  PROCEDURE  affordance  adds  an  HTN  to  an  entity’s  goal  stack 
rangelnMeters  at  which  an  entity  can  sense  that  an  affordance  exists  , 
type  of  affordance  (PROCEDURE  or  INFORMATION) 

data  (for  a  PROCEDURE  affordance  this  will  usually  be  the  location  of  an  HTN) 


#  STEP  3  -  INVERTED  GATEKEEPER 

################################################################################# 

#  creates  an  invertedGateKeeper  which  is  used  in  the  HTN  to  tell  entities  what  affordances  to  listen  for 

#  this  method  must  be  run  after  the  affordances  have  been  initialized 

#  this  method  must  be  run  before  process  Affordances  .  xml  is  added  to  each  entity’s  goal  stack 
affordanceUtilities  .  createlnvertedGateKeeperQ 


#  STEP  4  -  TELL  ENTITIES  TO  LISTEN  FOR  AFFORDANCES 
################################################################################# 

#  enable  designated  entities  to  listen  for  affordances 

#  must  be  done  for  all  entities  that  need  to  access  affordances 

#  must  be  done  after  the  invertedGateKeeper  has  been  created 

#  NOTE:  this  affordance  is  added  to  an  entity’s  "  affordanceStack "  and  not  its  primary  goal  stack 

listOfEntityNames  =  [] 

for  entityName  in  listOfEntityNames: 

UtilityFuncsExp  .  addSpecificGoal  ( 
entityName  , 

1.0, 

"HTN/ Trees  /  process  Affordances  .xml"  , 

"affordanceStack"  , 

[]  - 

None) 


HstOfUnitNames  =  [] 

for  unitName  in  HstOfUnitNames : 

UtilityFuncsExp  .  addS pecificGoalToUnit  ( 
unitName  , 

1.0, 

"HTN/ Trees  /  process  Affordances  .xml"  , 
"affordanceStack"  , 

[]  , 

None ) 


#  STEP  5  —  import  this  script  into  the  scenario’s  jump  start  file 
################################################################################### 


#  print  a  debug  message 
print  " " 

print  "  af f or d an c e I n i t i a  1  i za t i o n  complete" 
print  " " 
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APPENDIX  E: 

Core  Security  Formation  Behavior  Files 


These  are  the  primary  files  utilized  to  create  the  security  formation  behavior. 


E.l  securityFormationLibrary.py 

This  script  contains  functions  that  are  utilized  by  the  security  formation  behavior  files. 

import  math 

from  java,  util  import  Vector 
from  HTN  import  UtilityFuncsExp 

from  cxxi  .  model .  knowledge  .  group  .  holders  import  NewUnitHolder 


#  assigns  the  appropriate  moveOrderHTN  to  units  contained  in  the  ’  orderedMasterDapVector  ’ 

#  this  function  is  called  in  ’  masterSecFormV  1  .  xml  ’  and  in  ’  unitMoveOrderHTN  .  xml  ’ 

def  assignSecurityFormationPositionsToUnits  (orderedMasterDapVector  ,  perimeterLocations Vector  , 
directionsToLocations Vector  ,  unitFirstPositionNumber  ,  debugBoolean  )  : 
nextUnitFirstPositionNumber  =  unitFirstPositionNumber 

if  debugBoolean: 

print  "  orderedMasterDapVector " 
print  orderedMasterDapVector 

#  this  loop  cycles  through  each  DAP  in  the  orderedMasterDapVector 
for  i  in  range  (  len  (  orderedMasterDapVector  ))  : 

#  determines  the  locations  the  unit  is  responsible  for  occupying 

#  these  locations  were  originated  within  masterSecurityFormation  .  xml 
currentUnitFirstPositionNumber  =  nextUnitFirstPositionNumber 
currentUnitName  =  orderedMasterDapVector  [  i  ]  [0] 
currentUnitParent  Value  =  orderedMasterDapVector  [  i  ][  1  ] 
numberEntitiesInCurrentUnit  =  orderedMasterDapVector  [  i  ]  [2] 

nextUnitFirstPositionNumber  =  currentUnitFirstPositionNumber  +  numberEntitiesInCurrentUnit 
currentUnit  =  NewUnitHolder  .  retrieveUnitByName  ( currentUnitName  )  #  of  type  OrganizationalUnit 

#  this  collects  information  on  the  unit  itself  (does  not  include  subordinate  units) 
currentUnitMembers  =  currentUnit  .  getMembers  () 
numberMembersInCurrentUnit  =  len  (  currentUnitMembers  ) 

#  this  collects  information  on  the  entire  unit  (including  subordinate  units) 
totalCurrentUnitMembers  =  currentUnit  .  getAllUnitMembers  () 
totalNumberMembersInCurrentUnit  =  len  ( totalCurrentUnitMembers  ) 

if  debugBoolean: 

print  "CURRENT  UNIT  NAME" 
print  currentUnitName 

print  "NUMBER  OF  MEMBERS  IN  CURRENT  UNIT" 
print  numberMembersInCurrentUnit 
print  "TOTAL  NUMBER  OF  MEMBERS  IN  CURRENT  UNIT" 
print  totalNumberMembersInCurrentUnit 


#  a  PARENT  unit  is  by  its  nature  a  SIMPLE  unit 

#  if  the  PARENT  unit  has  members  in  it  ,  then  it  will  execute  simpleUnitMoveOrderHTN .  xml 
if  currentUnitParent  Value  ==  "PARENT"  and  numberMembersInCurrentUnit  >  0: 
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firstEntityFromCurrentUnitMembers  =  currentUnitMembers  [0] 
entityName  =  firstEntityFromCurrentUnitMembers  .  getAssignedName  () 

UtilityFuncsExp  .  addGoal ( 
s  tr  ( entityName  )  , 

0.1  , 

"HTN/Trees/ simpleUnitSecurityFormation  .xml"  , 

[  perimeterLocations Vector  ,  directionsToLocations Vector  ,  currentUnitFirstPositionNumber  ]  , 
None) 


elif  currentUnitParentValue  ==  "PARENT"  and  not  numberMembersInCurrentUnit  >  0  and  debugBoolean : 
print  " simpleUnitMoveOrderHTN  not  added  to  parent  unit  because  parent  unit  was  destroyed 
################################" 


#  a  CHILD  unit  could  be  either  SIMPLE  or  COMPLEX 

#  if  the  CHILD  unit  has  members  in  it  ,  then  it  will  execute  unitMoveOrderHTN .  xml 
elif  currentUnitParentValue  ==  "CHILD"  and  totalNumberMembersInCurrentUnit  >  0: 

firstEntityFromTotalCurrentUnitMembers  =  totalCurrentUnitMembers  [0] 
entityName  =  firstEntityFromTotalCurrentUnitMembers  .  getAssignedName  () 

UtilityFuncsExp  .  addGoal ( 
s  tr  (  entityName  )  , 

0.1  , 

"HTN/  Trees  /  unitSecurityFormation  .  xml "  , 

[  perimeterLocations  Vector  ,  directionsToLocations  Vector  ,  currentUnitFirstPositionNumber  ,  currentUnitName  ]  , 
None) 


elif  currentUnitParentValue  ==  "CHILD"  and  not  totalNumberMembersInCurrentUnit  >  0  and  debugBoolean: 
print  "unitMoveOrderHTN  not  added  to  child  unit  because  entire  unit  was  destroyed 
##################################### " 


#  angles  must  be  entered  in  radians 

def  calculateSecurityFormationPositions  (  arcBetweenPersonnel  ,  formationOrientation  ,  angleToCover  ,  numberActivePersonnel  , 
debugBoolean )  : 

degreesInCircle  =  360 
radiansInCircle  =  2  *  math. pi 

i f  debugBoolean  : 

print  ("FUNCTION  PARAMETERS") 

print  ("  arcBetweenPersonnel  ="  ,  arcBetweenPersonnel ) 
print  ("  formationOrientation  ="  .formationOrientation) 
print  ("  angleToCover  ="  .angleToCover) 

print  ("  numberActivePersonnel  ="  .numberActivePersonnel) 
print () 

atcPercentOfCircle  =  angleToCover /  radiansInCircle 

scaledNumber ActivePersonnel  =  numberActivePersonnel  /  atcPercentOfCircle 
#print  ("  scaledNumberActivePersonnel  =",scaledNumberActivePersonnel) 

circleCircumference  =  scaledNumberActivePersonnel  *  arcBetweenPersonnel 
#print  ("  circleCircumference  =",  circleCircumference) 
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circleRadius  =  circleCircumference  /  (2*math.pi) 

#print("circleRadius  =  ", circleRadius) 

individual AngleResponsibility  =  angleToCover  /  numberActi vePersonnel 
#print  ("  individualAngleResponsibility  =" ,  individualAngleResponsibility  ) 

directionToCounterClockwiseLimit  =  formationOrientation  —  ( angleToCover /2) 

# print  ("  directionToCounterClockwiseLimit  =",directionToCounterClockwiseLimit) 

directionToFirstPosition  =  directionToCounterClockwiseLimit  +  ( individual  AngleResponsibility /2) 

#print  ("  directionToFirstPosition  =",  directionToFirstPosition  ) 

i f  debugBoolean  : 

print  () 

print  ("LIST  POSITION  INFORMATION") 

HstOfPolarPlotsToPositions  =  [] 

for  i  in  range  (  numberActivePersonnel )  : 

directionToCurrentPosition  =  directionToCounterClockwiseLimit  +  ( individual  AngleResponsibility /2)  +  i*( 
individualAngleResponsibility) 

if  directionToCurrentPosition  <  0: 

directionToCurrentPosition  =  directionToCurrentPosition  +  2*math.pi 
polarToCurrentPosition  =  [directionToCurrentPosition,  circleRadius] 
if  debugBoolean  : 

print  ("  polar  plot  to  position  ",i  +  l,"  is",  polarToCurrentPosition) 

HstOfPolarPlotsToPositions  .  append  (polarToCurrentPosition) 

i f  debugBoolean  : 

print () 
print  O 

return  HstOfPolarPlotsToPositions 


#  the  "dap"  or  "decision  assignment  profile"  was  created  to  store  relevant  information  about  units 

#  this  "information  holder"  will  be  important  to  the  process  of  intelligently  assigning  units  to  positions  that  suit 

their  capabilities 

#  currently  it  only  includes  the  number  of  personnel  in  the  unit  and  whether  or  not  it  is  a  Parent  or  Child  unit 

#  eventually  ,  I  could  see  adding  information  about  what  type  of  weapons  the  unit  has,  ammunition  levels  ,  entity  health, 

etc  ... 

#  MIGHT  WANT  TO  THINK  ABOUT  CREATING  ’GETTERS’  FOR  DAP  VALUES 
def  createUnitDecisionAssignmentProfile  (  currentUnit  ,  parentEnum): 

currentUnitName  =  currentUnit  .  getName  () 
if  parentEnum  ==  "PARENT": 

numberEntitiesInCurrentUnit  =  determineNumberEntitiesInSimpleUnit(  currentUnit) 
elif  parentEnum  ==  "CHILD": 

numberEntitiesInCurrentUnit  =  determineNumberEntitiesInUnit(  currentUnit) 
else  : 

return  "ERROR  IN  DETERMINING  DECISION  ASSIGNMENT  PROFILE" 
unitDapVector  =  VectorQ 
unitDapVector.  add  (  currentUnitName  ) 
unitDapVector.  add  (  parentEnum  ) 

unitDapVector.  add  (numberEntitiesInCurrentUnit) 
return  unitDapVector 
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#  used  to  determine  number  of  entities  in  a  simple  unit  (unit  with  no  sub-units) 

#  there  are  simpler  ways  to  accomplish  this  such  as  using  the  ’getMembers’  command 

#  this  script  is  being  kept  because  it  could  eventually  be  used  to  help  build  a  unit’s  Decision  Assignment  Profile 
def  determineNumberEntitiesInSimpleUnit  (currentUnit)  : 

#currentUnitEntities  =  currentUnit  .  get AllEntities  ()  #  need  to  verify  that  this  is  the  correct  call 
currentUnitEntities  =  currentUnit  .  getMembers  ()  #  using  this  one  at  Imre’s  suggestion 

numberCurrentUnitEntities  =  len  (  currentUnitEntities  ) 
return  numberCurrentUnitEntities 


#  used  to  determine  number  of  entities  in  a  unit  which  is  potentially  complex  (has  sub-units);  heavy  recursion  here 

#  there  are  simpler  ways  to  accomplish  this  such  as  using  the  ’  getAllUnitMembers  ’  command 

#  this  script  is  being  kept  because  it  could  eventually  be  used  to  help  build  a  unit’s  Decision  Assignment  Profile 
def  determineNumberEntitiesInUnit(  currentUnit) : 

totalEntitiesInCurrentUnit  =  0 
currentUnitGroups  =  currentUnit  .  getGroups  () 
numberGroupsInCurrentUnit  =  len  (  currentUnitGroups  ) 
if  numberGroupsInCurrentUnit  >  0: 

for  i  in  range  (  numberGroupsInCurrentUnit )  : 
totalEntitiesInThisSubUnit  =  0 
if  len  (  currentUnitGroups  [  i  ].  getGroups  () )  >  0: 

totalEntitiesInThisSubUnit  =  determineNumberEntitiesInUnit(  currentUnitGroups  [  i  ]) 
else  : 

totalEntitiesInThisSubUnit  =  determineNumberEntitiesInSimpleUnit(  currentUnitGroups  [i  ]) 
totalEntitiesInCurrentUnit  =  totalEntitiesInCurrentUnit  +  totalEntitiesInThisSubUnit 
totalEntitiesInCurrentUnit  =  totalEntitiesInCurrentUnit  +  determineNumberEntitiesInSimpleUnit  (  currentUnit ) 
elif  numberGroupsInCurrentUnit  ==  0: 

totalEntitiesInCurrentUnit  =  determineNumberEnti  tie  sin  Simple  Unit  (currentUnit) 
else  : 

return  "ERROR  IN  DETERMINING  NUMBER  ENTITIES  IN  UNIT" 
return  totalEntitiesInCurrentUnit 


#  simple  math  function  performed  a  few  times  in  the  HTNs 
def  flipDegreeDirectionl  80  (directionln  Degrees): 
directionln  Degrees  =  directionln  Degrees  +  180 
if  directionlnDegrees  >=  360: 

directionlnDegrees  =  directionlnDegrees  —  360 
return  directionlnDegrees 


E.2  master  SecurityFormation.xml 

This  is  the  primary  HTN  that  is  utilized  to  instantiate  a  security  formation.  masterSe- 
curityFormation  conducts  the  majority  of  the  calculations  needed  to  determine  a  security 
formation’s  geometry.  This  file  activates  the  unitSecurityFormation  HTN. 

<?xml  version  =  "  1 .0  "  encoding  =  "UTF— 8"  standalone  =  " no "  ?><HTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name=" 

masterSecurityFormation"  Type="DEFAULT"xParent>null<  /  ParentxDataMapxDataKey>recur  si  on  Descriptor  ,  java  .  lang  . 

String  ,  "RECURSIVE"  or  "NONRECURSIVE" </ DataKeyxDataKey>arrayListOfUnitNames  ,  j ava  .  u  t  i  1  .  ArrayList  ,  names  of  units  to 
participate  in  formation  </ DataKeyxDataKey>  way  Point  ,  cxxi  .  model .  objects  .  features  .  CMWayPoint</DataKeyxDataKey> 
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arcBetweenLocations  ,  java  .  lang  .  Double  ,  meters</DataKey><DataKey>formationOrientation  ,  java  .  lang  .  Double  ,  radiansc/ 
DataKeyxDataKey>angleToCover  ,  java  .  lang  .  Double  ,  radians</DataKey><DataKey>formationCenterDescriptor  ,  java  .  lang  . 

String  ,  "FLOT"  or  "CENTER"</DataKeyxDataKey>convexConcaveString  ,  java  .  lang  .  String  ,  "CONVEX"  (normal)  or  "CONCAVE"  ( 
inverted  formation  )</ DataKeyxDataKey>useIsCommanderBoolean  ,  java  .  lang  .  String  ,"True"  or  "  False  ”</ DataKeyx/DataMap> 
<Code  IsFile  =  "  false  " /xlmport /xHTNNode  AllowMsg="  true  "  BreakPoints  =  "  "  Name="  initlnfo  "  Type="DEFAULT"xParent> 
masterSecurityFormationc/  ParentxCode  IsFile  =  "  false  ">if  _gt_activeNode  .  getVar( "  islnited  ")  ==  None: 

_gt_activeNode  .  putVar("  islnited",  1) 

_htn_precon_ret=l 

</  Codexlmport  /  xHTNNode  AllowMsg="  true"  BreakPoints  =  ""  Name="  isCommander "  Type="DEFAULT"xParent>  ini  tin  f  o  <  /  ParentxCode 
IsFile  =  "  false  ">useIsCommanderBoolean  =  _gt_activeNode  .  getParam  ( "  uselsCommanderBoolean  " ) 

if  uselsCommanderBoolean  ==  "True": 
if  state  .  isCommander  ()  : 

_htn_precon_ret=l 

elif  uselsCommanderBoolean  ==  "False": 

_htn_precon_ret=l 

else: 

printMessage  ( "ERROR  WITH  uselsCommanderBoolean",  True  )</CodexImport /xHTNNode  AllowMsg="  fal  se  "  BreakPoints  =  " "  Name=" 
getNumberPersonnel "  Type="DEFAULT"xParent>isCommander</  ParentxCode  IsFile="  false  ">from  cxxi  .  model .  knowledge  . 
group  .  holders  import  NewUnitHolder 
from  HTN  import  security FormationLibrary 


arrayListOfUnitNames  =  _gt_activeNode.  getParam  ("arrayListOfUnitNames") 
recursionDescriptor  =  _gt_activeNode.  getParam  ("recursionDescriptor") 


numberTotalEntities  =  0 

for  i  in  range  ( len  (  arrayListOfUnitNames  ))  : 
currentUnitName  =  arrayListOfUnitNames  [  i  ] 

currentUnit  =  NewUnitHolder  .  retrieveUnitByName  (  currentUnitName  )  #  of  type  OrganizationalUnit 
if  recursionDescriptor  ==  "RECURSIVE": 

numberEntitiesInCurrentUnit  =  securityFormationLibrary  .  determineNumberEntitiesInUnit(  currentUnit) 
elif  recursionDescriptor  ==  "NONRECURSIVE": 

numberEntitiesInCurrentUnit  =  securityFormationLibrary.  determineNumberEntitiesInSimpleUnit  (currentUnit) 
else : 

printMessage  ("ERROR  IN  ENTERING  RECURSION  DESCRIPTOR",  True) 
numberTotalEntities  =  numberTotalEntities  +  numberEntitiesInCurrentUnit 


####################################################### 

##  I  chose  not  to  use  these  commands  on  purpose 

##  I  believe  using  the  above  commands  presents  an  opportunity  to  build  on  the  "DAP"  concept 
#members  =  currentUnit  .  getAHUnitMembers  () 

#alternateNumberMembers  =  len  (members) 

#printMessage  ("  alternate  numberTotalEntities  =  "  +  s tr  (  alternateNumberMembers  )  ,  True) 
############################################################## 


printMessage  ("  numberTotalEntities  =  "+ s tr  (  numberTotalEntities  )  ,  True) 


gt_activeNode  ,putVar("  numberTotalEntities"  ,  numberTotalEntities) 


</CodexImport /x/HTNNodexHTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name="  isDestroyedUnit "  Type=”DEFAULT"xParent> 
isCommander</  ParentxCode  IsFile  =  "false">numberTotalEntities  =  _gt_activeNode  ,getVar("  numberTotalEntities") 
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if  numberTotalEntities  ==  0: 

_htn_precon_ret  =  l</Code><Import /xHTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name=" exitHTN  "  Type=''GOAL"xParent> 
isDestroyedUnitc  /  ParentxCode  IsFile  =  "  false  "> 
printMessage  ( "NO  ENTITIES  IN  UNIT;  MASTER  SECURITY  FORMATION  EXITING",  True) 

</CodexImport /x/HTNNodex/HTNNodexHTNNode  AllowMsg="  fal se  "  BreakPoints  =  " "  Name="  calculatePolars  "  Type=  "DEFAULT" x 
Parent>isCommander</ ParentxCode  IsFile="  false  ">from  HTN  import  securityFormationLibrary 
import  math 

numberTotalEntities  =  _gt_activeNode  ,getVar("  numberTotalEntities") 
arcBetweenLocations  =  _gt_activeNode.  getParam  ("arcBetweenLocations") 
formationOrientation  =  _gt_activeNode.  getParam  ("formationOrientation") 
angleToCover  =  _gt_activeNode  .  getParam( "  angleToCover" ) 


printMessage  ("  numberTotalEntities  =  "+  str  (  numberTotalEntities  )  ,  True) 

listOfPolarPlotsToPositions  =  securityFormationLibrary  .  calculateSecurityFormationPositions( 
arcBetweenLocations  , 
formationOrientation  , 
angleToCover  , 
numberTotalEntities  , 

False  ) 

_gt_activeNode  .  putVar("  listOfPolarPlotsToPositions",  listOfPolarPlotsToPositions) 
printMessage  ("  listOfPolarPlotsToPositions  =  "+str  ( listOfPolarPlotsToPositions  )  ,  True) 

</CodexImport /x/HTNNodexHTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name="  findPerimeterLocations  "  Type="DEFAULT"xParent> 
isCommander</ ParentxCode  IsFile  =  "  false  ">from  mtry  .  cxxi  .  model .  HierarchicalTaskNetwork  import  HTNUtilities 
from  java,  util  import  Vector 

from  cxxi  .  model .  behavior  import  OrderUtilities 
import  math 

from  HTN  import  securityFormationLibrary 


#  get  parameters  and  variables 

inputtedPosition  =  _gt_activeNode  .  getParam  ("  wayPoint " ) 

formationCenterDescriptor  =  _gt_activeNode.  getParam  ("formationCenterDescriptor") 
formationOrientation  =  _gt_activeNode.  getParam  ("formationOrientation") 
listOfPolarPlotsToPositions  =  _gt_activeNode.getVar("  listOfPolarPlotsToPositions") 
circleRadius  =  listOfPolarPlotsToPositions  [0]  [  1  ] 

convexConcaveString  =  _gt_activeNode  .  getParam  ("convexConcaveString") 

#  establish  new  variables 
perimeterLocations  Vector  =  VectorQ 
directionsToLocations  Vector  =  VectorQ 


#  convert  orientation  from  radians  to  degrees 

formationOrientationlnDegrees  =  (formationOrientation  /  math  .  pi )  *  180 


#  assesses  formation  Center  Descriptor  value  (center  or  forward  line  of  troops) 
if  formationCenterDescriptor  ==  "CENTER"  : 

circleCenterLocationWithAGL  =  inputtedPosition  .  getLocationWithAGL  () 
elif  formationCenterDescriptor  ==  "FLOT"  : 
if  convexConcaveString  ==  "CONVEX": 

initialCenterLocationWithAGL  =  inputtedPosition  .  getLocationWithAGL  () 

oppositeFormationOrientationlnDegrees  =  securityFormationLibrary  .  flipDegreeDirectionl80( 
formationOrientationlnDegrees) 
circleCenterLocationWithAGL  =  HTNUtilities  .  _py_offsetLoc  ( 
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initialCenterLocationWithAGL  , 
oppositeFormationOrientationlnDegrees  , 
circleRadius  )  ; 

elif  convexConcaveString  ==  "CONCAVE": 

initialCenterLocationWithAGL  =  inputtedPosition  .  getLocationWithAGL  () 

oppositeFormationOrientationlnDegrees  =  securityFormationLibrary  .  flipDegreeDirectionl80( 
formationOrientationlnDegrees) 
circleCenterLocationWithAGL  =  HTNUtilities  .  _py_offsetLoc  ( 
initialCenterLocationWithAGL  , 
formationOrientationlnDegrees  , 
circleRadius  )  ; 

else : 

printMessage  ( "ERROR  IN  ENTERING  convexConcaveDescriptor  "  ,  True) 
else: 

printMessage  ("ERROR  IN  ENTERING  FORMATION  CENTER  DESCRIPTOR",  True) 


#  determines  the  locations  of  the  security  positions 
for  i  in  range  ( len  ( listOfPolarPlotsToPositions  )) : 

#printMessage  ( "  polarToPosition  =  "  +  str  ( listOfPolarPlotsToPositions  [  i  ])  ,  True) 

direction  =  listOfPolarPlotsToPositions  [  i  ]  [0] 
directionlnDegrees  =  (  direction /math  .  pi )  *180 

#  activated  if  formation  is  of  type  "CONCAVE" 
if  convexConcaveString  ==  "CONCAVE": 

directionlnDegrees  =  securityFormationLibrary  .  flipDegreeDirection  180  (directionlnDegrees) 


distance  =  listOfPolarPlotsToPositions  [  i  ][  1  ] 

currentPerimeterLocation  =  HTNUtilities  .  _py_offsetLoc  (  circleCenterLocationWithAGL  ,  directionlnDegrees,  distance); 
perimeterLocationsVector  .  add(  currentPerimeterLocation) 


#  this  conditional  is  not  actually  needed  because  ’  directionsInDegrees  ’  is  not  used  again 

#  but  I  kept  it  in  because  it  helps  remind  me  how  these  CONCAVE  calculations  work 
#if  convexConcaveString  ==  "CONCAVE": 

#  directionlnDegrees  =  dynamicManeuverWork  .  flipDegreeDirection  1  80  (  directionlnDegrees  ) 


directionsToLocationsVector  .  add(  direction  ) 


#  saves  the  locations  of  the  security  positions 

_gt_activeNode  ,putVar(  "perimeterLocationsVector",  perimeterLocationsVector) 
_gt_activeNode  ,putVar(  "directionsToLocationsVector",  directionsToLocationsVector) 


</CodexImport /></HTNNodexHTNNode  AllowMsg="  false  "  BreakPoints  =  " "  Name="  acti vateSubordinateHTNs  "  Type="GOAL"xParent> 
isCommander</ ParentxCode  IsFile  =  "  false  ">from  HTN  import  UtilityFuncsExp 
from  HTN  import  securityFormationLibrary 

recursionDescriptor  =  _gt_activeNode  .  getParam("recursionDescriptor") 
perimeterLocationsVector  =  _gt_activeNode  .  getVar("  perimeterLocationsVector") 
directionsToLocationsVector  =  _gt_activeNode.getVar("  directionsToLocationsVector") 
array  List  Of  Uni  tNames  =  _gt_activeNode  .  get  Par  am  ( "  array  Lis  tOfUnitNames  " ) 


#  establish  new  variables 
unitFirstPositionNumber  =  0 
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unorderedMasterDapVector  =  VectorQ  #  DAP/Dap  stands  for  "Decision  Assignment  Profile" 
orderedMasterDapVector  =  VectorQ 


#  create  DAPs  for  the  top  level  units  and  store  them  inside  a  vector 

#  DAPs  for  RECURSIVE  and  NONRECURSIVE  formations  should  be  different 

#  as  DAP  functionality  is  increased  ,  it  is  important  to  ensure  that  this  function  continues  to  work  properly 
for  i  in  range  ( len  (  arrayListOfUnitNames  ))  : 

currentUnitName  =  arrayListOfUnitNames  [  i  ] 

currentUnit  =  NewUnitHolder  .  retrieveUnitByName  (  currentUnitName  )  #  of  type  OrganizationalUnit 

#  if  using  recursive  option,  classify  all  units  as  CHILD  —  this  way  they  are  treated  as  potentially  complex  units 

#  if  using  nonrecursive  option,  classify  all  units  as  PARENT  —  this  way  they  are  treated  as  simple  units 
if  recursionDescriptor  ==  "RECURSIVE": 

currentUnitDap  =  securityFormationLibrary  .  createUnitDecision  AssignmentProfile  (  currentUnit  ,  "CHILD") 
elif  recursionDescriptor  ==  "NONRECURSIVE"  : 

currentUnitDap  =  securityFormationLibrary  .  createUnitDecision  AssignmentProfile  (  currentUnit  ,  "PARENT") 
else : 

printMessage(  "ERROR  IN  ENTERING  RECURSION  DESCRIPTOR",  True) 


unorderedMasterDapVector.  add(  currentUnitDap) 


############################################################################## 

#  THIS  IS  THE  LOCATION  WHERE  THE  INTELLIGENT  "DECISION"  CAN  BE  MADE  CONCERNING 

#  HOW  UNITS  SHOULD  BE  PLACED  WITHIN  THE  OVERALL  FORMATION 

#  DO  THIS  BY  ORDERING  the  units  described  in  ’unorderedMasterDapVector’ 
orderedMasterDapVector  =  unorderedMasterDapVector 
############################################################################### 


securityFormationLibrary  .  assignSecurityFormationPositionsToUnits  (  orderedMasterDapVector  ,  perimeterLocationsVector  , 
directionsToLocationsVector  ,  unitFirstPositionNumber  ,  False) 

printMessage  ( "MasterHTN  Move  To  Position  Node  Complete",  True  )</CodexImport /></HTNNodex/HTNNode></HTNNodex/HTNNode> 


E.3  unitSecurityFormation.xml 

This  is  the  second  HTN  that  is  utilized  to  instantiate  a  security  formation.  unitSecurityFor- 
mation  was  designed  to  work  with  future  mechanisms  that  will  intelligently  locate  subunits 
within  a  single  security  formation.  This  file  recursively  activates  itself,  or  it  activates  the 
simpleUnitSecurity Formation  HTN. 

<?xml  version  =  "  1 .0  "  encoding  =  "UTF— 8"  standalone  =  "no"  ?><HTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name=" 

unitSecurity Formation  "  Type="DEFAULT"xParent>null</ ParentxDataMapxDataKey>perimeterLocationsVector  ,java.  util  . 
Vector</DataKeyxDataKey>directionsToLocationsVector  ,java.  util  .  Vector</DataKeyxDataKey>unitFirstPositionNumber  , 
java  .  lang  .  Integer</DataKeyxDataKey>unitName  ,  java  .  lang  .  S tringc/ DataKeyx/DataMapxCode  IsFile  =  "  false  "/xlmport/x 
HTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name="  initlnfo  "  Type="DEFAULT"xParent>unitSecurityFormation</ ParentxCode 
IsFile  =  "  false  ">if  _gt_activeNode  .  getVar( "  islnited  " )  ==  None: 

_gt_activeNode  .putVar("  islnited",  1) 

_htn_precon_ret=l 

</  Codexlmport  /xHTNNode  AllowMsg="  false"  BreakPoints  =  ""  Name="  processlnformation"  Type="GOAL"xParent>initInfo<  /  Parent  > 
<Code  IsFile  =  "  false  ">from  java,  util  import  Vector 
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from  HTN  import  security FormationLibrary 
from  HTN  import  Utility FuncsExp 

from  cxxi  .  model .  knowledge  .  group  .  holders  import  NewUnitHolder 


printMessage  (  "EXECUTING  unitMoveOrderHTN  "  ,  True) 

perimeterLocationsVector  =  _gt_activeNode.  getParam  ("perimeterLocationsVector") 
directionsToLocations  Vector  =  _gt_activeNode.  getParam  ("directionsToLocationsVector") 
uni  tFirstPositionN  umber  =  _gt_activeNode.  getParam  ("  uni  tFirstPositionN  umber") 

#  important  to  get  the  unit  in  this  manner;  the  entity  executing  this  HTN  may  not  be  in  the  unit  executing  the  action 
unitName  =  _gt_activeNode  .  getParam  ("  unitName  " ) 

currentUnit  =  NewUnitHolder .  retrieveUnitByName  ( unitName )  #  of  type  OrganizationalUnit 
printMessage  ("  unitName  to  execute  =  "+ s  tr  (  unitName )  ,  True) 
currentUnitGroups  =  currentUnit  .  getGroups  () 

printMessage  ("  currentUnitGroups  =  "+str  (  currentUnitGroups  )  ,  True) 


#  if  this  is  a  simple  unit  (no  sub-units),  then  adds  simpleUnitMoveOrderHTN  to  its  goal  stack 
if  len  (  currentUnitGroups  )  ==  0: 

printMessage  ("  unitMoveOrderHTN  IS  EXECUTING  A  simpleUnitMoveOrderHTN",  True) 

currentUnitMembers  =  currentUnit  .  getMembers  () 
firstEntityFromCurrentUnitMembers  =  currentUnitMembers  [0] 
entity  Name  =  firstEntityFromCurrentUnitMembers  .  getAssignedName  () 

UtilityFuncsExp  .  addGoal( 
s  tr  (  entityName  )  , 

0.1  , 

"HTN/  Trees /simpleUnitSecurityFormation.  xml"  , 

[perimeterLocationsVector  ,  directionsToLocationsVector  ,  unitFirstPositionNumber  ]  , 

None ) 


#  activates  if  this  is  a  complex  unit  (with  sub-units);  below  code  displays  recursive  properites  of  unitMoveOrderHTN 

#  dap  stands  for  "decision  assignment  profile";  it  was  created  to  store  info  about  units 

#  see  security  FormationLibrary  .  py  for  more  details 
elif  len  (  currentUnitGroups  )  &gt  ;  0: 

#  create  new  variables 
unorderedMasterDap  Vector  =  VectorQ 
orderedMasterDapVector  =  VectorQ 

#  creates  a  dap  for  the  unit’s  headquarters  element  (which  itself  is  a  simple  unit) 
parentUnitDap  =  securityFormationLibrary  .  createUnitDecisionAssignmentProfile  (  currentUnit  ,  "PARENT") 
printMessage  ("  parentUnitDap  =  "+ s  tr  (  parentUnitDap  )  ,  True) 

unorderedMasterDapVector.  add  (parentUnitDap) 

#  creates  daps  for  the  unit’s  sub-units  (these  units  may  be  simple  or  complex) 
for  i  in  range  ( len  (  currentUnitGroups  ))  : 

currentChildUnit  =  currentUnitGroups  [i] 

currentChildUnitDap  =  securityFormationLibrary  .  createUnitDecisionAssignmentProfile  (  currentChildUnit  ,  "CHILD") 
unorderedMasterDapVector.  add(  currentChildUnitDap) 

printMessage  ("  unorderedMasterDapVector  =  "  +  str  (unorderedMasterDapVector)  ,  True) 


169 


71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

1 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 


############################################################################## 

#  THIS  IS  THE  LOCATION  WHERE  THE  INTELLIGENT  "DECISION"  CAN  BE  MADE  CONCERNING 

#  HOW  UNITS  SHOULD  BE  PLACED  WITHIN  THE  PARENT  UNIT  FORMATION 

#  DO  THIS  BY  ORDERING  UNITS  DESCRIBED  IN  ’  unorderedM asterDap Vector  ’ 
orderedMasterDap  Vector  =  unorderedMasterDapVector 
############################################################################## 


#  this  function  adds  unitMoveOrderHTN / simpleUnitMoveOrderHTN  to  the  units  described  in  the  orderedMasterDapVector 
securityFormationLibrary.assignSecurityFormationPositionsToUnits( 
orderedMasterDapVector  , 
perimeterLocationsVector  , 
directionsToLocations Vector  , 
unitFirstPositionNumber  , 

False) 


<  /  Code  ><  Import/  ><  /  HTNNodex  /  HTNNodex  /  HTNNode> 


E.4  simpleU  nitSecurityF  ormation.xml 

This  is  the  third  HTN  that  is  utilized  to  instantiate  a  security  formation.  simpleU nitSecu- 
rityFormation  was  designed  to  work  with  future  mechanisms  that  will  intelligently  locate 
individual  entities  within  a  security  formation.  This  file  activates  the  basicIndividualMove 
HTN. 

<?xml  version  =  "  1 .0  "  encoding  =  "UTF— 8"  standalone  =  "no"  ?xHTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name=" 

simpleU  nitSecurityFormati  on"  Type="DEFAULT”xParent>null<  /  Parent  xDataMapxDataKey>perimeterLoc  at  ions  Vector  ,  java  . 
util  .  Vector</DataKeyxDataKey>directionsToLocationsVector  ,java.  util  .  Vector</DataKeyxDataKey> 

unitFirstPositionNumber  ,java  .  lang  .  Integerc/ DataKeyx/DataMapxCode  IsFile  =  "  false  "/xlmport  /xHTNNode  AllowMsg=" 
true"  BreakPoints  =  " "  Name="  initlnfo  "  Type="DEFAULT"xParent>simpleUnitSecurityFormation</ ParentxCode  IsFile  =  " 
false">if  _gt_activeNode  .  getVar  ( "  islnited  " )  ==  None: 

_gt_activeNode  .  putVar(”  islnited",  1) 

_htn_precon_ret=l 

</CodexIm port /xHTNNode  AllowMsg="  false  "  BreakPoints  =  " "  Name="  processlnformation  "  Type="GOAL"xParent>initInfo</ Parent> 
<Code  IsFile  =  "  false  ">printMessage(  "EXECUTING  SIMPLE  UNIT  MOVE  ORDER  HIN"  ,  True) 

perimeterLocationsVector  =  _gt_activeNode.  get  Par  am  ("perimeterLocationsVector") 
directionsToLocationsVector  =  _gt_activeNode.  get  Par  am  ("directionsToLocationsVector") 
unitFirstPositionNumber  =  _gt_activeNode.  get  Par  am  ("unitFirstPositionNumber") 

state  .  changeFormation  ( "NO_FORMATION"  ,  "overrideFillScript") 


positionNumberForEntity  =  unitFirstPositionNumber 
unitToIter  =  state  .  getCurrentUnit  () 

totalNumberMembers  =  0 


######################################################################################################### 
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#  assigns  individualMoveHTN  to  members  of  this  unit 

#  right  now  position  assignment  is  simply  made  in  the  order  that  the  entities  are  listed 

#  to  "intelligently"  assign  entities  to  positions  that  match  their  capabilities  ,  this  is  a  place  to  do  it 
######################################################################################################### 


#for  member  in  unitToIter.getAllEntities(): 
for  member  in  unitToIter  .  getMembers  ()  : 

totalNumberMembers  =  totalNumberMembers  +  1 

UtilityFuncsExp  .  addGoal( 

str  (member.  getAssignedName  () )  , 

0.1  . 

"HTN/  Trees  /  basiclndi  vidualMove  .xml"  , 

[perimeterLocationsVector[positionNumberForEntity],directionsToLocationsVector[positionNumberForEntity]], 
None ) 

positionNumberForEntity  =  positionNumberForEntity  +  1 
printMessage(  "MEMBER  NAME="+member .  getAssignedName  ()  ,  True  ) 

printMessage  ("  totalNumberMembers  =  "  + s  tr  ( totalNumberMembers  )  ,  True  )</Code><Import /></HTNNodex/HTNNodex/HTNNode> 


basicIndividualMove.xml 


This  is  the  fourth  HTN  that  is  utilized  to  instantiate  a  security  formation,  basiclndividual- 
Move  moves  entities  to  their  assigned  positions.  This  HTN  is  for  demonstration  purposes 
and  is  intended  to  be  replaced  by  a  behavior  mechanism  which  more  accurately  represents 
the  ways  that  entities  move  in  combat  situations. 


<?xml  version  =  "  1 .0  "  encoding  =  "UTF— 8"  standalone  =  "no"  ?><HTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name=" 

basicIndividualMoveHTN  "  Type="DEFAULT"xParent>null</  ParentxDataMapxDataKey>locationToGoTo  ,  cxxi  .  model .  physics  . 
geometry  .  Location</DataKeyxDataKey>directionToLookInRadians  ,  java  .  lang  .  Doublec/ DataKeyx/DataMapxCode  IsFile  =  " 
false  " /xlmport /xHTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name="  initlnfo  "  Type="DEFAULT"xParent> 
basicIndividualMoveHTNc/ ParentxCode  IsFile  =  "  false  ">if  _gt_activeNode  .  getVar  ( "  i  s I n i  t e  d  " )  ==  None: 

_gt_activeNode  .putVar("isInited",  1) 

_htn_precon_ret=l 

</CodexImport /xHTNNode  AllowMsg="  false  "  BreakPoints  =  " "  Name="  moveToPosition  "  Type="GOAL"xParent>initInfo</ Parentx 
Code  IsFile  =  "  false  ">from  cxxi  .  model .  behavior  import  OrderUtilities 
from  java,  util  import  Vector 
import  math 

printMessage  ("  executing  individual  move  HTN"+str  ( info  .  getMyAssignedName  () )  ,  True) 
locationToGoTo  =  _gt_activeNode  .  getParam  ( "  locationToGoTo  " ) 

directionToLookln Radians  =  _gt_activeNode.  getParam  ("directionToLooklnRadians") 
directionToLooklnDegrees  =  (directionToLooklnRadians  /  math  .  pi )  *  180 

compoundOrder  =  OrderUtilities  .  movelntoPosition  ( locationToGoTo  ,  3.0,  directionToLooklnDegrees) 
orders  .  addOrder  ( compoundOrder ) 

<  /  Codex  I  m  p  o  r  t  /  x  /  HTNNodex  /  HTNNodex  /  HTNNode> 


171 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


172 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 


APPENDIX  F: 

Modifiers  to  Security  Formation  Behavior 


The  following  HTNs  are  used  to  modify  the  security  formation  behavior’s  functionality. 

F.l  removeUnitFromAffSecForm.xml 

This  HTN  removes  units  from  security  formations  which  were  initially  established  with 
a  procedural  affordance  that  utilized  the  masterS ecurity Formation  or  security Forma- 
tion  by Phase A/fordanceMoc!  HTN s . 

<?xml  version  =  "  1 .0  "  encoding  =  "UTF— 8"  standalone  =  " no "  ?><HTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name=" 

removeUnitFromAffSecForm "  Type="DEFAULT"xParent>null</  ParentxDataMapxDataKey>wpNameInSits  ,  java  .  lang  .  Stringc/ 
DataKeyxDataKey>listOfUnitNamesToRemove  ,  java  .  util  .  ArrayList</DataKeyxDataKey>controlMeasureToMoveTo  ,  cxxi  .  model . 
objects  .  features  .  CMWayPoint</  DataKeyxDataKey>newFormationParameterBoolean  , java. lang. String,  "True"  or  "  False  "</ 
DataKeyxDataKey>newArcBetweenLocations  ,  java  .  lang  .  Double  ,  in  metersc/DataKeyx/DataMapxCode  IsFile  =  "  false  "  />< 

Import /xHTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name="  initlnfo  "  Type="DEFAULT"xParent>removeUnitFromAffSecForm</ 
ParentxCode  IsFile  =  "  false  ">if  _gt_activeNode  .  getVar  ( "  islnited  " )  ==  None: 

_gt_activeNode  .  putVar("  islnited",  1) 

_htn_precon_ret=l 

</CodexImport /xHTNNode  AllowMsg="  false  "  BreakPoints  =  " "  Name="doWork"  Type="GOAL"xParent>initInfo</ ParentxCode  IsFile 
=  "  false  ">from  HTN  import  UtilityFuncsExp 
from  java,  util  import  ArrayList 

from  mtry  .  cxxi  .  model .  behaviorextensions  import  RuleMappingSupport 
from  mtry  .  cxxi  .  model .  affordances  import  affordanceUtilities 
import  math 
import  random 

from  cxxi  .  model .  knowledge  .  group  .  holders  import  NewUnitHolder 


####################################################################################### 

#  THIS  HTN  WAS  DESIGNED  SPECIFICALLY  TO  WORK  WITH  SECURITY  FORMATIONS  THAT 

#  WERE  INSTANTIATED  BY  A  PROCEDURAL  AFFORDANCE  WHICH  UTILIZED  EITHER 

#  masterSecurityFormation  .  xml  OR  securityFormation_byProcessingUnit  .  xml 
######################################################################################### 


wpNamelnSits  =  _gt_activeNode  .  getParam  ( "  wpNamelnSits " ) 

listOfUnitNamesToRemove  =  _gt_activeNode.  getParam  ( "  listOfUnitNamesToRemove  " ) 
controlMeasureToMoveTo  =  _gt_activeNode.  getParam  ( "  controlMeasureToMoveTo  " ) 
new  For  mat  ionParame  ter  Boole  an  =  _gt_activeNode.  getParam  ("newFormationParameterBoolean") 
newArcBetweenLocations  =  _gt_activeNode  .  getParam  ( "  newArcBetweenLocations  " ) 


htnParameterList  =  affordanceUtilities  .getListOfHtnParameters  (wpNamelnSits) 


############################################################################################ 

#  THIS  COULD  BREAK  IF  THE  HTN  PARAMETERS  ARE  CHANGED 

#  THE  INDEX  NUMBER  MUST  CORRESPOND  TO  THE  unitNames ArrayList 
unitNamesArrayList  =  htnParameterList  [  1  ] 

############################################################################################ 
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for  unitNameToRemove  in  listOfUnitNamesToRemove: 


if  unitNames ArrayList  .  contains  (unitNameToRemove) : 
unitN ames  ArrayList  .  remove  ( unitNameToRemove ) 


currentUnit  =  NewUnitHolder .  retrieveUnitByName  (unitNameToRemove)  #  of  type  OrganizationalUnit 


#listOfCurrentEntities  =  currentUnit  .  get AllEntities  () 

listOfCurrentEntities  =  currentUnit  .  getMembers  ()  #  NEED  TO  VERIFY  THIS  IS  CORRECT  METHOD  TO  CALL 


printMessage  ("  current  entities  =  "  +  str  ( listOfCurrentEntities  )  ,  False) 
for  currentEntity  in  listOfCurrentEntities: 

currentEntityName  =  currentEntity  .  getAssignedName  () 

#printMessage  ( "  currentEntityName  =  "  + s  tr  (  currentEntityName  )  ,  False) 

UtilityFuncsExp  .  addGoal ( 
currentEntityName  , 

0.1  , 

"HTN/  Trees  /  basiclndi  vidualMove  .xml"  , 

[  controlMeasureToMoveTo  ,getLocation()  ,  random  .  uniform  (0,2.0*  math  .  pi )  ]  , 
None) 


htnParameterList  =  affordanceUtilities.getListOfHtnParameters  ( wpNamelnSits  ) 


############################################################################################ 

#  THIS  COULD  BREAK  IF  THE  HTN  PARAMETERS  ARE  CHANGED 

#  THE  INDEX  NUMBER  MUST  CORRESPOND  TO  THE  arcBetweenLocations 
if  newFormationParameterBoolean  ==  "True": 

printMessage  ("  using  new  formation  parameters".  False) 
htnParameterList  [3]  =  newArcBetweenLocations 
elif  newFormationParameterBoolean  ==  "False": 

printMessage  ("  not  using  new  formation  parameters".  False) 
else: 

printMessage  ("  error  has  occurred  with  newFormationParametersBoolean "  ,  False) 
############################################################################################ 


UtilityFuncsExp  .  addGoal ( 

info  .  getMyAssignedName  ()  , 

0. 1  , 

"HTN/  Trees  /  masterSecurityFormation  .  xml"  , 
htnParameterList  , 

None )  <  /  Codex  I  mp  o  r  t  /  ><  /  HTNNodex  /  HTNNodex  /  HTNNode> 


F.2  securityFormationJbyPhaseAffordanceMod.xml 

This  HTN  is  intended  to  be  utilized  in  conjunction  with  a  procedural  affordance.  Units  that 
activate  this  procedural  affordance  are  integrated  into  a  single  security  formation. 

<?xml  version  =  "  1 .0  "  encoding  =  "UTF— 8"  standalone  =  "no"  ?><HTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name=" 

sec urityFormation_by Phase AffordanceMod  "  Type="DEFAULT"xParent>null <  /  ParentxDataMapxDataKey>affordanceName  ,  java  . 
lang  .  Stringc/ DataKeyxDataKey>recursionDescriptor  ,  java  .  lang  .  String  /'RECURSIVE"  or  "NONRECURSIVE" </ DataKeyxDataKey 
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>arrayListOfUnitNames  ,  java  .  util  .  Array  List  </ DataKeyxDataKey>  way  Point  ,  cxxi .  model .  objects  .  features  .  CMWayPointc/ 
DataKeyxDataKey>arcBetweenLocations  ,  java  .  lang  .  Double</DataKeyxDataKey>formationOrientation  ,  java  .  lang  .  Double  , 
radians</DataKeyxDataKey>angleToCover  ,  java  .  lang  .  Double  ,  radians</DataKeyxDataKey>formationCenterDescriptor  ,  java  . 
lang  .  String  ,  "FLOT"  or  ”CENTER"</ DataKeyxDataKey>convexConcaveString  ,  java  .  lang  .  String  ,  "CONCAVE"  if  want  the 
formation  in verted</DataKeyxDataKey>useIsCommanderBoolean  ,  j ava  .  lang  .  String  ,"True"  or  "  False  "</DataKeyx/DataMapx 
Code  IsFile  =  "  false  " /xlmport /xHTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name="  initlnfo  "  Type="DEFAULT"xParent> 
securityFormation_byPhaseAffordanceMod</ ParentxCode  IsFile  =  "  false  ">if  _gt_activeNode  .  getVar  ( "  i  s  I n i  t ed  " )  ==  None: 
_gt_activeNode  ,putVar("isInited",  1) 

_htn_precon_ret=l 

</  Codexlmport  /  xHTNNode  AllowMsg="  true"  BreakPoints  =  ""  Name="  isCommander "  Type="DEFAULT"xParent>  ini  t  In  f  o  <  /  ParentxCode 
IsFile  =  "  false  ">useIsCommanderBoolean  =  _gt_activeNode  .  getParam( "  uselsCo mmander Boolean  " ) 

if  uselsCommanderBoolean  ==  "True": 
if  state  .  isCommander  ()  : 

_htn_precon_ret=l 

elif  uselsCommanderBoolean  ==  "False": 

_htn_precon_ret=l 

else: 

printMessage  ( "ERROR  WITH  uselsCommanderBoolean",  True  )</CodexImport /xHTNNode  AllowMsg="  fal  se  "  BreakPoints  =  " "  Name=" 
activateMasterSecurityFormation"  Type="GOAL"xParent>isCommander<  /  ParentxCode  IsFile  =  "  false  ">from  cxxi .  model . 
behavior  import  OrderUtilities 
import  UtilityFuncs 
from  HTN  import  UtilityFuncsExp 
from  java,  util  import  Set 

from  mtry  .  cxxi  .  model .  affordances  import  affordanceUtilities 
import  copy 


goalPath  =  "HTN/  Trees  /  masterSecurityFormation  .  xml" 
affordanceName  =  _gt_activeNode  .  getParam  ( "  affordanceName  " ) 

currentParameterList  =  affordanceUtilities  .getListOfHtnParameters  (affordanceName) 

printMessage  ("  currentParameterList  =  "+str  (  currentParameterList )  ,  True) 

unitName  =  state  .  getCurrentUnitName  () 
printMessage  ( "UNIT  NAME  =  "+ s  tr  ( unitName  )  ,  True) 


############################################################################################ 

#  THIS  COULD  BREAK  IF  THE  HTN  PARAMETERS  ARE  CHANGED 

#  THE  INDEX  NUMBER  MUST  CORRESPOND  TO  THE  unitNamesArrayList 
if  not  currentParameterList  [2] .  contains  (  str  (unitName) )  : 

currentParameterList  [2] .  add  (  str  ( unitName  ) ) 

printMessage  (  s  tr  ( unitName )  +  "  added  to  unit  parameter  list",  True) 
else: 

printMessage(str(  unitName )  +  "  NOT  ADDED  TO  UNIT  PARAMETER  LIST  (DUPLICATE  ISSUE)",  True) 
############################################################################################# 


updatedParameterList  =  affordanceUtilities  .getListOfHtnParameters  ( wpNamelnSits ) 
shallowCopyUpdatedParameterList  =  copy  .  copy  (currentParameterList) 

printMessage  ("  shallowCopyUpdatedParameterList  =  "  + s  tr  (  shallowCopyUpdatedParameterList )  ,  True) 

#  removes  the  first  item  from  the  shallowCopyUpdatedParameterList 

#  this  is  done  because  masterSecurity Formation  .  xml  does  not  use  this  item  as  one  of  its  parameters 
shall owCopy UpdatedParameterList  .  pop  (0) 
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UtilityFuncsExp  .  addGoal  ( 
info  .  getMyAssignedName  ( )  , 

0.1  , 

goalPath  , 

shallowCopyUpdatedParameterList  , 

None) 

<  /  Codex  Imp  o  rt  /  ><  /  HTNNodex  /  HTNNodex  /  HTNNodex  /  HTNNode> 


F.3  security  F  ormationjby  ProcessingU  nit.xml 

The  unit  that  processes  this  HTN  establishes  a  security  formation. 

<?xml  version  =  "  1 .0  "  encoding  =  "UTF— 8"  standalone  =  "  no "  ?xHTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name=" 

securityFormation_byProcessingUnit"  Type="DEFAULT"xParent>null</  ParentxDataMapxDataKey>recursionDescriptor  ,  java 
.  lang  .  String  ,  "RECURSIVE"  or  "NONRECURSIVE" </ DataKeyxDataKey>arrayListOfUnitNames  ,  java  .  util  .  ArrayListc/ DataKeyx 
DataKey>wayPoint  ,  cxxi  .  model .  objects  .  features  .  CMWayPoint</DataKeyxDataKey>arcBetweenLocations  ,  java  .  lang  .  Double</ 
DataKeyxDataKey>formationOrientation  ,  java  .  lang  .  Double  ,  radians</DataKeyxDataKey>angleToCover  ,  java  .  lang  .  Double  , 
radians</DataKeyxDataKey>formationCenterDescriptor  ,  java  .  lang  .  String  ,  "FLOT"  or  "CENTER"</DataKeyxDataKey> 
convexConcaveString  ,  java  .  lang  .  String  ,  "CONCAVE"  if  want  the  formation  inverted</DataKeyxDataKey> 
uselsCommanderBoolean  , java. lang. St  ring,  "True"  or  "False  "</ DataKeyx/ DataMapxCode  IsFile="  false  "/xlmport/x 
HTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name="  initlnfo  "  Type="DEFAULT"xParent>securityFormation_byProcessingUnit</ 
ParentxCode  IsFile  =  "  false  ">if  _gt_activeNode  .  getVar  ( "  islnited  " )  ==  None: 

_gt_activeNode  .putVar("  islnited",  1) 

_htn_precon_ret=l 

</  Codexlmport  /xHTNNode  AllowMsg="  true"  BreakPoints  =  ""  Name="  isCommander "  Type="DEFAULT"xParent>  ini  tlnf  o  <  /  ParentxCode 
IsFile="  false  ">useIsCommanderBoolean  =  _gt_activeNode.  getParam  ( "  uselsCommanderBoolean  " ) 

if  uselsCommanderBoolean  ==  "True": 
if  s t at e  .  isCommander  ()  : 

_htn_precon_ret=l 

elif  uselsCommanderBoolean  ==  "False": 

_htn_precon_ret=l 

else: 

printMessage  ( "ERROR  WITH  uselsCommanderBoolean",  True  )</CodexImport /xHTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name=" 
acti vateMasterSecurityFormation  "  Type="GOAL”xParent>isCommander</  ParentxCode  IsFile  =  "  false  ">from  cxxi .  model . 
behavior  import  OrderUtilities 
import  UtilityFuncs 
from  HTN  import  UtilityFuncsExp 
from  java,  util  import  Set 

from  mtry  .  cxxi  .  model .  affordances  import  affordanceUtilities 
import  copy 


goalPath  =  "HTN/  Trees  /  masterSecurityFormation  .  xml" 

unitName  =  state  .  getCurrentUnitName  () 
printMessage  ( "UNIT  NAME  =  "+ s  tr  (  unitName  )  ,  True) 
unitNamesArrayList  =  ArrayListQ 
unitName  s  Array  Li  st  .  add(  str  (unitName) ) 

recursionDescriptor  =  _gt_activeNode  .  getParam  ("recursionDescriptor") 
wayPoint  =  _gt_activeNode  .  getParam  ("  wayPoint " ) 

arcBetweenLocations  =  _gt_activeNode.  getParam  ("arcBetweenLocations") 
formationOrientation  =  _gt_activeNode.  getParam  ("formationOrientation") 
angleToCover  =  _gt_activeNode  .  getParam( "  angleToCover " ) 

formationCenterDescriptor  =  _gt_activeNode  .  getParam  ("formationCenter  Descriptor") 
convexConcaveString  =  _gt_activeNode.  getParam  ("convexConcaveString") 
uselsCommanderBoolean  =  _gt_activeNode.  getParam  ( "  uselsCommanderBoolean  " ) 


parameterList  =  [recursionDescriptor,  unitNamesArrayList,  wayPoint,  arcBetweenLocations,  formationOrientation, 
angleToCover,  formationCenterDescriptor,  convexConcaveString,  uselsCommanderBoolean] 
printMessage  ( "new  security  formation  param  list  =  "  +  str  (  parameterList )  ,  True) 
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41  UtilityFuncsExp  .  addGoalToUnit  ( 

42  unitName  , 

43  0.1, 

44  goalPath  , 

45  parameterList  , 

46  None )  <  /  Codex  I  m  p  o  r  t  /  ><  /  HTNNodex  /  HTNNodex  /  HTNNodex  /  HTNNode> 
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APPENDIX  G: 

Modifiers  to  SquadMove  Behavior 


The  following  HTNs  are  used  to  modify  the  functionality  of  the  SquadMove  HTN. 


G.l  SquadMove_MoveDesignatedUnits.xml 

When  this  HTN  is  activated,  units  that  are  included  in  a  list  all  conduct  a  SquadMove 
behavior. 


<?xml  version  =  "  1 .0  "  encoding  =  "UTF— 8"  standalone  =  " no "  ?><HTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name=" 

SquadMove_MoveDesignatedUnits  "  Type="DEFAULT"xParent>null</  ParentxDataMapxDataKey>unitNameToExecuteList  ,  java  . 
util  .  ArrayList</DataKeyxDataKey>start_loc  ,  cxxi  .  model .  objects  .  features  . CMWayPointc/ DataKeyxDataKey>end_loc  ,  cxxi  . 
model .  objects  .  features  .  CMWayPointc/ DataKeyx/DataMapxCode  IsFile="  false  "  /xlmport /xHTNNode  AllowMsg="  true  " 
BreakPoints  =  ""  Name="  initlnfo  "  Type="DEFAULT"xParent>SquadMove_MoveDesignatedUnits<  /  ParentxCode  IsFile  =  "  false  "> 
if  _gt_activeNode  .  getVar  ( "  islnited  " )  ==  None: 

_gt_activeNode  .putVar("  islnited",  1) 

_htn_precon_ret=l 

</  Codexlmport  /  xHTNNode  AllowMsg="  true"  BreakPoints  =  ""  Name="  isCommander "  Type="DEFAULT"xParent>  ini  tlnf  o  <  /  ParentxCode 
IsFile  =  "  false  ">if  state.  isCommander  ()  : 

_htn_precon_ret=l 

</  Codexlmport  /  xHTNNode  AllowMsg="  false"  BreakPoints  =  ""  Name="  movelnFormation  "  Type="GOAL"xParent>isCommander<  /  Parent> 
<Code  IsFile  =  "  false  ">from  HTN  import  UtilityFuncsExp 
from  java,  util  import  ArrayList 


unitNameToExecuteList  =  _gt_activeNode.  get  Par  am  ( "  unitNameToExecuteList " ) 
start_loc  =  _gt_activeNode  .  getParam  ( "  start_loc  " ) 
end_loc  =  _gt_activeNode  .  getParam  ("  end_loc  " ) 

#  set  the  path  to  the  goal 
goalPath  =  "HTN/ Trees /SquadMove  .  xml" 

for  unitNameToExecute  in  unitNameToExecuteList: 

#  add  the  goal  to  a  unit 
UtilityFuncsExp  .  addGoalToUnit ( 
unitNameToExecute  , 

0.1  , 

goalPath  , 

[start_loc  ,  end_loc], 

None ) 


<  /  Code  x  I  m  p  o  r  t  /  ><  /  HTNNodex  /  HTNNodex  /  HTNNodex  /  HTNNode> 


G.2  SquadMove_OtherUnitsInArrayList.xml 

This  HTN  contains  a  list  of  units  that  are  intended  to  conduct  a  SquadMove  behavior.  If 
the  unit  that  processes  this  HTN  is  included  in  that  list,  then  all  units  except  the  processing 
unit  conduct  a  SquadMove  behavior. 
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<?xml  version  =  "  1 .0  "  encoding  =  "UTF— 8"  standalone  =  "  no "  ?><HTNNode  AllowMsg="  true  "  BreakPoints  =  " "  Name=" 

SquadMove_Other  Unit  sin  Array  Li  st "  Type="DEFAULT"xParent>null</  ParentxDataMapxDataKey>unitNameToExecuteList  ,  java  . 
util  .  ArrayList</ DataKeyxDataKey> start_loc  ,  cxxi  .  model .  objects  .  features  .  CMWayPoint</ DataKeyxDataKey>end_loc  ,  cxxi  . 
model .  objects  .  features  . CMWayPointc/ DataKeyx/DataMapxCode  IsFile  =  "  false  " /xlmport /xHTNNode  AllowMsg="  true  " 
BreakPoints  =  " "  Name="  initlnfo  "  Type="DEFAULT"xParent>SquadMove_OtherUnitsInArrayList</ ParentxCode  IsFile  =  "  false  " 
>if  _gt_activeNode  .  getVar  ( "  i  slnited  " )  ==  None: 

_gt_activeNode  .putVar(”isInited",  1) 

_htn_precon_ret=l 

</  Codexlmport  /  xHTNNode  AllowMsg="  true"  BreakPoints  =  ""  Name="  isCommander "  Type="DEFAULT"xParent>  ini  tin  f  o  <  /  ParentxCode 
IsFile  =  "  false  ">if  state.  isCommander  ( )  : 

_htn_precon_ret=l 

</ Codexlmport  /xHTNNode  AllowMsg="  false  "  BreakPoints  =  " "  Name="  movelnFormation  "  Type="GOAL"xParent>isCommander</  Parent> 
<Code  IsFile  =  "  false  ">from  HTN  import  UtilityFuncsExp 
from  java,  util  import  ArrayList 

#  the  purpose  of  this  HTN  is  to  move  the  units  in  the  unitNameToExecuteList  that  DO  NOT  activate  this  HTN 

#  this  is  one  tool  that  enables  units  in  the  urbanPatrolDemonstration  to  bound  past  one  another 

unitNameToExecuteList  =  _gt_activeNode.  get  Par  am  ("unitNameToExecuteList") 
start_loc  =  _gt_activeNode  .  getParam  ( "  start_loc  " ) 
end_loc  =  _gt_activeNode  .  getParam  ("  end_loc  " ) 

printMessage  ( "  originalUnitNameToExecuteList  =  "+ str  (  unitNameToExecuteList )  ,  True) 
myUnitName  =  state  .  getCurrentUnitName  () 
if  unitNameToExecuteList .  contains  (myUnitName)  : 
unitNameToExecuteList .  remove  ( myUnitName ) 

printMessage  ("  updatedUnitNameToExecuteList  =  "+ s  tr  (  unitNameToExecuteList )  ,  True) 
unitNameToExecute  =  unitNameToExecuteList  [0] 

printMessage  ("  unitNameToExecute  =  "+  s tr  ( unitNameToExecute  )  ,  True) 

#  set  the  path  to  the  goal 
goalPath  =  "HTN/ Trees /SquadMove  .  xml" 


#  add  the  goal  to  a  unit 
UtilityFuncsExp  .  addGoalToUnit  ( 
unitNameToExecute  , 

0.1  , 

goalPath  , 

[start_loc  ,  end_loc  ]  , 

None) 

<  /  Codex  I  m  p  o  r  t  /  x  /  HTNNodex  /  HTNNodex  /  HTNNodex  /  HTNNode> 
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